When we are faced with the challenge of developing an application for a client, many things happen even before we start writing the first lines of code.

In this series of articles we are going to try to break down each of the steps that directly affect developers.  Go further into the most common problems when facing the challenge of successfully completing the creation of a quality application for our client.

Therefore, before starting to write our code we have to deal with a series of problems:

  1. Requirements capture phase.
  2. Development and production environments.
  3. Safe code and teamwork.

If we manage to reduce the number of problems that arise in these three steps prior to writing our first lines of code, we can ensure that our application will be much easier to create, and with a much higher quality than if we start programming from the outset in order to avoid deliverying it late.

The first and perhaps one of the most essential parts is the client requirements capture phase. Unfortunately, in many work environments, this phase tends to be underestimated, as it is thought that if a lot of time is spent on it, then time isn’t being invested in actually getting on with development. This type of error is what leads us to misunderstand what the client wants from the application, and then, when we are already in the middle of the development phase, things that have not been included, have been incorrectly defined, or misinterpreted by us; upon delivery of the application to the client, it becomes clear that this is not what the client wanted. This, in turn, leads to having to make a series of changes that could be disastrous for our planning. Therefore, this is a phase that must be very well defined, and investing a few hours in it could prevent entire days being wasted in the development phase, in addition to the wariness that we could instill in the client as it will have seen that we have not been able to interpret its needs.

Therefore, once we are sure of the requirements, it is very simple  to create mockups or prototypes without functionality that are delivered to the client so that it can visually validate the functionality that is presented as a solution to its requirements. If there is something missing, misinterpretation or fault, it can be quickly corrected, only h aving to moify these mockups, until hitting on exactly what the client needs.

Furthermore, this technique allows us to offer, in a visual way, solutions that the client had not thought could be useful until that time and that could facilitate both the development and the requirements of the application, with the resulting cost savings and, what is even more important, client satisfaction upon seeing, in a simple way, valid solutions to their problems and value alternatives to the software that is being developed.

It is also of great use to us in order for our application to have a high UX level(user experience), that is easy to use by users themselves, since they are the ones who can tell us which options are the most used in their day-to-day life and give it greater weight and accessibility within the application, and what ones are not used so frequently, giving them a less important role in the application and thus being able to create clear and simple interfaces for the users. We can achieve this by presenting these mockups to the users themselves and asking them to validate them, since developers cannot really know what features are more or less used if it doesn’t take into account the end user’s own experience.

And finally, when it comes to starting programming, it is much simpler to be able to present the requirements of the application to the programmers, showing these mockups, and directly indicating what is needed, having a global vision of the functionality of the application with a few slides, and a detailed view of the parts to be dealt with by each programmer, it is easier to assign tasks by distributing the mockups between the work groups.

In order to make these mockups we use the Balsamiq tool, which we will present below in a simple way to show the power of this technique, but there are many more tools to implement them on the market.

As a basic example, we will develop a CRUD for the user management of our application.

From the client requirements capture phase we learn that it wants to be able to manage the users who have access to the application, being able to register, deregister and modify them. These users can belong to different groups that will allow access to different parts of the application depending on the permissions that each group has been assigned. The client also wants to be able to activate and deactivate users temporarily if at any time it wants to prevent any of them from accessing it. Each user must have a name and a password that they can manage themselves from within the application, not just the system administrators.

With this requirements capture we propose the following mockups that we develop with Balsamiq.

For this article we are using the test version in a web environment associated with Google Drive, there are several other alternatives, such as desktop, or in the cloud, if you are more comfortable with them.

This can be seen in the following way:

The upper part is where the functionalities that allow us to manage the projects are, as the tool allows to create all the mockups belonging to an application in the same project.

Just below, all the editing and visualization options appear. In addition, it also offers the possibility of collaboration, allowing other users to have access to the project and to collaborate on it if invited to do so by the owner.

Now in the work interface itself, we can see all the controls that can be used to simulate the possible objects that we will use to create our application.

 

Incorporating the possibility of adding new controls through a link that shows us more possibilities that are growing little by little on the application’s website.

The work area is divided into three parts

 

The left part where we will find the mockups of each of the screens.

The central part, where we will develop each of the mockups by dragging the controls of the upper bar, and editing them by double clicking on them, and on the right side, the properties of each of the controls that we are incorporating, and where, apart from the appearance, we can control the events that are associated with each of the controls, because when we activate presentation mode we can interact with each of the defined controls as if it were the application itself, giving a live demonstration that our client can interact with.

We will check the result of our mockups associated with the specifications we have obtained from our client requirements capture phase in this example.

Requirements capture:

The client wants to be able to manage the users who have access to the application.

being able to regsiter

deregister,

and modify.

These users can belong to different groups that will allow access to different parts of the application depending on the permissions that each group has been assigned.

The client also wants to be able to activate and deactivate users temporarily if at any time it wants to prevent any of them from accessing it.

Each user must have a name and a password that they can manage themselves, not just the system administrators.

With each and every one of these mockups we have collected all the features that the client has requested for the application. At this time, if we show the presentation mode which I have included as a video, the client can see, visually and directly, if it is what it needs or if, on the contrary, it wants some changes to be made.

For example, the client may indicate that the order of the grid fields in which the users appear is not to its liking, because it prefers the user groups to appear before the active column.

We can quickly modify the mockup and show it to the client in order to see the desired effect.

And with this, the client verifies that this is what it needs.

After having a clear idea about the specification and once the entire application has been verified by the client, we can now hand it over to our developers, who will have a very clear idea of ​​the client’s needs and can apply them more easily by turning the initial idea into a reality.

In our case we show some examples of the mockups brought to life in the application.

I hope this brief presentation of this first problem that we came across before starting to programme an application, and the tool that allows us to solve it, have helped you.

Luckily, technology is not only available to our clients, and we, as developers, also have the possibility of using tools that help us to implement programming techniques that allow us to develop quality software at a lower cost. In this way we will satisfy our customers, and we can also enjoy our work much more, not having to deal with delays and tight planning schedules due to errors made at the very beginning.

For the next article we will focus on the development and production environments where we will implement our applications. This issue is also problematic, and for this we will again make use of technologies that make our lives easier, in this case virtual machines, that allow us to simulate these environments independently from the software and that will facilitate us, among other things, to carry out a whole range of tests to deliver quality software, but this is another issue…

See you with the next article.