About your new prototype

 "What technology to use to create a prototype and how detailed should it be"

 

...seems to be a definite discussion point for any project that includes prototyping.
However, today when I ended up reading a post on this, I felt an irresistible desire to cover this topic here as well ...

In general, I have figured out a few pointers that should guide the prototype in terms of the level of detail and the choice of technology:

1. When you start deciding on what technology or prototyping tool to use, you should make sure that the initial task is clearly defined.

Coding languages ​​are good tools for prototyping if the initial task is clear and understandable. That is because an unambiguous task tends to require less reworking afterwards.

However, code-writing has advantages in terms of authenticity and later reuse. It makes it easier to understand the limitations and possibilities of the new technology. And reusing code that already exists can significantly reduce the time spent on the development process. :). In case of such low-variable projects, the benefits may outweigh the effort of greater prototyping.

2. When writing a prototype through code (HTML, CSS, PHP, Java widgets), creating a prototype for one form is several times more expensive, even without significant repair needs.

Because:

• the prototyper (often yourself) must be proficient in the programming language, highly skilled people are more expensive;
• the prototype is over-detailed because you intend to use the code on the finished product;
• repeated use of the prototype code never happens 100%; usually, it is around 10%.

 3. Technical people, such as architects and programmers, prefer a prototyping model with technical capabilities. This is because in general, they can't accept the idea of ​​throwing things away or doing something again.

Preference is emotional and shaped by "religion." You can't fight emotions with emotions. Sober and sound reasoning is an option if you can make two things clear:

• why the prototype's developer can't develop himself with new and exciting technology;
• why someone has to redo the work that has already been done.

4. When asking a client whether to choose cheaper work that can be discarded or more expensive and permanent work, 90% of clients choose the more expensive part.

It is not pleasant to pay for a dead horse, even if it is very cheap. A soft result like a tested idea and solution is not measurable in the eyes of many people. If you can explain how exactly the model benefits the client, then the horse doesn't seem to be so dead anymore.

5. The idea of a prototype is to enable change cheaply and often. The purpose of this is to ensure that we already know what the good solution is if we should start working on an expensive project later on, which would in turn mean that we would not have to spend more valuable time on it.

Draft-draft-draft. Otherwise, you could create a real system right away; why even spend time on some prototype.

6. People can never manage large systems as a whole. So you will never get a perfect prototype of your system done on your first attempt. This point does not apply to a small system with a small navigation of up to 25 pages and a few main functions (article view, search).

Complex systems evolve gradually and change over the course of testing. Think, for example, of evolution ...

7. It is advised never to show a prototype to management without design elements. Often, the management is unable to evaluate it. It is also why expensive prototypes are usually created at the client's premises, where IT projects are less frequent.

This does not apply if the management is one of the evaluators. They have not taken the time to delve into the content. Pictures however are always easier to evaluate, and 75% of people decide based on their gut feeling...

If showing the prototype to the management does not provide meaningful input, then you'll need to think about presenting less beautiful prototypes. A simple calculation of profitability during the planning phase helps a lot here.

A prototype is often the first visual solution to a long-awaited, new system that will solve all of the client's problems. Frustration is easy to come in which case, high expectations will not arise for a very long time. This is the point where the idea has become something "tangible", and having a definite goal and a plan will help keep the impatience under control.

8. If you make a prototype completely without design elements, it may be necessary to make changes to the final solution during the development process. Changes made after the prototype phase are many times more expensive.

The design often helps to test the solution. The problems stand out better, so you can't do without design elements completely. However, you can do everything at a reasonable level.

9. If you create a prototype with the complete final visual design, then people will mainly evaluate the design and the ease of use of some of the features to a smaller extent.

It is easier to evaluate design. It is more "real" for everyone, and everyone has an opinion about it, even if they cannot justify it. The ease of use of the functions, the navigation scheme, and the order of the objects do not usually evoke emotions. Therefore, it is more sensible to create an imperfectly smoothed out design and to identify as much information as possible with indirect questions already in the analysis phase.

10. If the prototype has more than 50 pages and contains a fully polished design, then everyone will only evaluate the design.

The evaluation of large systems should be done in small parts and preferably by function. A person can't understand all possible connections - it takes a long time to learn them.

11. The sales staff turns pale when you talk about a prototype that visually, does not look exactly like the system that is being created. An hour-long heated conversation could follow this...

There are people who spend their days explaining why we do something better than everyone else... And now, such a perceived shortcoming! To avoid this problem, you need to help the sales staff sell the exact solution required for a specific project right from the start.

12. Prototypes are created for different reasons. In some cases, an exact copy of the system being developed is needed. In others, you may just need a draft. In most cases, a combination of both is required.

Some prototypes are simply in the form of images; others are moving (dynamic). Find out whether there are precise requirements set for the prototype or are possible solutions simply being played through to see how much each design influences the user trying to achieve their goal. There are solutions for all needs (prototyping tools, technical implementation).

The prototype can be a documented and detailed initial task or a black and white form drawn on paper. Both can be tested and evaluated. The difference is in the work methods, the results and the price.

13. And last but not least. Don't fixate on your "faith".

In some cases, the most unacceptable idea may be the only solution to a problem. Picking usability techniques is the skill for which you were chosen as the specialist and not someone else instead of you.

Enjoy the challenges and life will be a breeze :)