Continuity from prototype to software

Those who deal with web design and software development in general are well aware of the “fidelity” problem that comes up every time a graphic interface has to be transformed into code by the developer. What’s the solution? Probably the fact that there isn’t a real problem.

The passage from the prototype to real software

A UI designer deals with interface design and to do so they use dedicated graphic software, such as the modern Sketch or Adobe XD, or the older and not recommended Adobe Illustrator (for these tasks Photoshop is ancient history by now).
The passage from the prototype phase to the development of a functioning version is a crucial moment of every software project (such as a web app for example) and it is the phase in which you are more likely to encounter issues.

It is the moment in which the most exceptional choices – not in the sense of incredible, but unusual – of the designer are reigned in by the developers and adapted to the existing component libraries, previously selected for the project based on various criteria. They are never drastic changes. Indeed only certain small details can undergo changes, showing up in the finished product looking different from how they were designed from the beginning.

If the graphic and prototyping phase have been planned carefully, the designers and developers have already excluded the more impractical graphic solutions from the start. Therefore the software that passes from the prototype to be an actual tool is not affected in its integrity and its fundamental functional aspects.
The changes that occur from prototype to software are more subtle, such as wider or more narrow margins, larger or smaller font sizes, different colors for icons and so on.
The question is: why do these discrepancies between prototypes and real interfaces exist?

Why are prototypes and software sometimes different?

At this point we need to ask ourselves: if the libraries are selected at the start of the project and the characteristics are known, why doesn’t the design simply follow what is set out by the available components?
Furthermore, since the interface design ends up adapting to the programming, thus “betraying” the identity of the prototype, why not put limitations from the very start?

The truth is that, while the above mentioned designer tools are almost always the same, and allow wide design freedom, the developer tools can vary from project to project (perhaps not in terms of programming language, but in terms of the framework used) and consequently the available libraries to be used also change.

The open source libraries are almost always administered by different teams with varying differences in objectives and philosophies; this can imply many different graphic and functional variations, also in cases in which two libraries have one or more components that seem apparently similar.

Therefore, to avoid issues deriving from the use of too many sets of specific graphic components (creation and update time), you need to adopt a more generic and varied approach, suitable to the comparison with the libraries, but as free as possible from specifics that are too pronounced.
This project compromise determines some of the minor inconveniences already mentioned in favour of other more significant work advantages, such as relieving the client of costs connected to the creation and maintenance of various components from extremely specific prototyping.

Another equally important aspect is related to the adherence of the prototypes to the design guidelines (ours is Material Design by Google) which never find direct correspondence in the library components. What is the reason for this? Guidelines are “designer stuff”, often released by specific company organisations (Google for example) while the real components, as mentioned, are developed by independent teams who pay less attention to details and work on different libraries from framework to framework.
These guidelines are essential to adhere to interface quality and visual consistency standards, since we are dealing with what can be seen and perceived, but they are only a guideline that belongs to an ideal/theoretical world. As experience shows, this theory often has to bow to the much less permissive real requirements, to the point that even Google web services don’t always fully adhere and may include components not in the Material Design manual.

100% adherence to the prototype is often a waste of time

For some clients these details are an element of friction: since they were presented and approved in a certain way, so it is more than fair to ask why they should change at the development phase, especially if you consider how simple they seem to change.
This sometimes happens because the topic seems intuitive when in truth it is particularly complex and deals with very technical aspects that make it difficult to explain to everyone in a simple way.

However, we cannot ignore two significant errors that should lead us to think about investing – we could say almost wasting – time in trying to adhere in every way to the prototype.

The first is believing that such marginal details are always essential for optimal software performance, which is not the case.
Aside from all the crucial aspects that determine the creation of a structure of this type and its level of user friendliness (such as user experiences for example) these are just frills.
The time spent for the implementation and the related maintenance problems are not often worth the little “esthetic” satisfaction.

The second is a misunderstanding about the role of the prototype and the prototyping phase. This phase of the project workflow is useful for preparing the software development and is needed, by the designers and the client, to preview, study and understand the structure, the layout and the dynamics that will define it in its finished form. It defines the structural and interactive characteristics and only subsequently the formal ones, where possible.

We must note that the issue revealed is not exclusively connected to the client’s expectations, on the contrary, keeping in mind the different competences, the legitimate wish to define the software characteristics in every small detail is shared by the UX/UI designer and the art director.
This is a limitation with which, very often, all the key members of the project have to compromise with.

To make a comparison, in other sectors in which the graphic aspect is essential – such as packaging design and advertising communication – the level of freedom and adherence to the finished product are often higher due to the lack of IT limitations. There are physical limitations of a different kind (image resolution, materials, colours etc.) but, usually, the whole design and revision process that leads to production can flow smoothly without costly obstacles and can have lower costs.
Since it often happens that people deal with more traditional graphics experiences, it is normal for them to expect the same flexibility in the software, even though the parallel is misleading and not completely correct.

Adherence to prototypes: yes or no?

In conclusion, when the interfaces are passed to the developer, to what point should the art director, the UI designer and the client demand adherence of the code to what was defined with the prototype? The right answer, we feel is: only to a certain extent.

In our experience at Dreamonkey and in our exchanges with other companies in our sector, for the moment we have reached the conclusion that any change is acceptable as long as it doesn’t significantly compromise the project workflow or the possibility to maintain the code in the long run. Among the various possible issues, the most common are the excessive delays to adapt the prototype to new requirements, to modify or design a new component or the doubt that the requests made could cause incompatibilities with future updates in development technologies, which can be complicated to manage. Obviously those who should have the last word – in theory – are the professionals due to their expertise.

What are your thoughts? Have you found a way to solve these issues effectively or have you reached our same conclusions? If you want to talk about it contact us.