It is normal that when implementing a design, situations arise that we have not foreseen. This does not have to be a mistake, it is simply sometimes impossible to foresee certain use cases or behaviors of our applications without spending dozens of hours defining a task. However, there are certain recurring patterns that tend to occur and it is the purpose of this post to identify and analyze them to streamline the development process if we run into them, such as facilitating the development flow.

Keep in mind that in many cases the data are longer than we may think at first.

The problem with texts that do not occupy the expected space is something very common in development. It is very nice to see in the designs a form such as:

Name: John
Last name: Snow
Email: jnieve@gmail.com

But the real world is hard and when you least expect it, a user appears with the following data:

Name: Francisco Javier
Last name: Sánchez del Pinar Garroguerricaechevarria
Email: franciscojaviersanchezdelpinarGarroguerricaechevarria1992@hotmail.com

What used to be a form cuqui has been transformed into a multi-line hell and nothing fits anymore. The email is cut in version mobile because the lack of space has not been taken into account and our precious form is now a mess.

To prevent this it is a good idea to think of all our users as royalty and have 30-character names.

You will surely find a suitable solution to this problem: grouping components in a more optimal way, reducing the size or using ellipsis in certain cases. Just remember that the problem with long names is common in development and it is better to be safe than sorry.

Plan how forms are validated

The use of forms is very common in the development of applications and having a clear idea of how to validate the possible fields to be processed can save development time.

Validating a form is nothing more than telling the user which fields are mandatory or have an incorrect format. A couple of examples of validation would be that an email does not exist in our database and that this email has a correct format.

It is common to have several designs of the form, one in its initial state with placeholders, one with inserted values and one with errors. Maybe another one with the inputs highlighted if the values are correct.

But when is each status displayed? In the case of correct fields it is simple: when correctly filled in and the values are correct, the corresponding styles will be applied. But, in the case of errors, there may be several options to deal with.

When we validate that a field is correct in a input For example, when typing a character, when changing the focus to another component of the form, when sending the form? It is a good idea to have this behavior defined beforehand to avoid possible surprises and deviations in the development if we have to change the validation system later on.

Implementing your design in a way that facilitates its implementation

Use tools that help developers to do their job. As a developer receiving designs in jpg is a nuisance. Are there really people who send their designs in jpg? I assure you there are, so please don't be like them.

Activate development mode (Dev Mode) in the design platform used will greatly help developers by providing specific tools that will save them time when implementing designs.

Note that data are not always returned.

Data will not always exist in our applications and we must take into account that this may happen.

It is very common in development to have questions like: What will we show if a particular table is empty? How will this view look if there is no description? What will happen if a user does not have a phone number (which in this case is not mandatory)?

Keeping in mind that there is a possibility that certain data may not exist will further speed up the development since there will be no blocking when these situations occur.

Knowing how views will behave in different resolutions

It is important to consider how our application will behave and be displayed in each of the sizes we support.

How will the texts adapt when the screen size changes? will they remain the same size? will they increase dynamically? will they change size based on defined breakpoints?

Since there is no single approach to screen size change, it is important to define its adaptability before starting development to avoid undesired behavior in the future.

On mobile devices the keyboard will appear when interacting with forms.

When we have forms in an application mobile we have to take into account that the device will display a keyboard so that the user can interact with the different fields of the forms. When this happens, this keyboard may occupy half of the screen (even more, in small devices).

It is important to define the behavior of our application when this happens. Will the content adapt when the keyboard appears? Will the content be pushed upwards? Will we not modify the content in these situations?

There is no correct solution for this case. However, foreseeing this behavior will save development time.

Conclusion: The importance of the development flow

If we had foreseen it, defining the validation behavior of a form would have taken no more than 5 minutes. Changing it afterwards will cost a few hours.

There may be cases that are not so flagrant. However, the cost of changing the behavior of an application when we already have a functionality developed is a waste of time, resources and, why not say it, an increase of our frustration.

Having detected the above situations (I'm sure you can think of a few more) will help us enormously to speed up the development process, reducing time and, consequently, costs.

Do you want more tips to improve your development? You can take a look at more articles from developers for developers here.