1. What do we need to start working on?

As previously mentioned, we need a construction plan, that should include:

Requirement analysis

UI Mockup and Visual Design defining a visual language

Design Prototype to enlighten flows and interactions

A collection of the required assets

Here is where we may found out the first criticality.

What generally happens is that all this stuff is provided at the very beginning and it does not evolve together with the project. It’s more like a portrait of the project at its starter time, this way ending up to be a constraint.

The reality suggests that the design process is iterative. It is closer to the process of creating an animated design, as well as a movie.

The first step should look like a draft of a storyboard, which is progressively modified, up to the final version, with the cooperation of developers, designers, clients, …

The design process is characterized by the fact that during developments it’s often necessary to make changes, fixes and/or improvements and this consistently occurs. In order to support this iterative flow, the construction plan needs to be reviewed over and over. Otherwise, mockups and prototypes can no longer be efficiently used as validation and testing tools.

Here’s where tools like Abstract, Living Style Guides, Storybook can come in handy.

2. What do we use to work?

Generally, we don’t start a project from scratch. That would be crazy! As soon as the construction plan is ready, we use to collect all the working tools which make us fasten and give a boost to our productivity. About this topic, I recently came across this article by my friend Sebastiano Guerriero from CodyHouse: Everyone uses CSS frameworks, which I suggest you read.

One of the main development tools we can use is the front end framework, which is a starting codebase that allows us to avoid doing the same things over and over again on every single project. This starter code must also be representative of a shared standard, must be maintained and documented.

First thing first, we should ask ourselves whether our starter code is really useful. In order to properly answer this question, we can start from the definition of usability:

Usability is defined by the ISO (International Organization for Standardization), such as the effectiveness, efficiency, and satisfaction with which certain users achieve certain objectives in specific contexts. In practice, it defines the degree of ease and satisfaction with which the interaction between man and an instrument takes place.

At this point, you can ask yourself:

Is the framework I’m using really usable?

Starting from the previous definition, we are able to identify the main bugs that affect the usability of our framework:

It may contain obsolete and deprecated code

It may be based on poor documentation and maintenance process

It may suffer a lack of standards and conventions

How we can fix these issues to increase effectiveness, efficiency, and satisfaction?

Let’s start by decluttering our code!

Remove things that you do not use so that you have more space and can easily find things when you need them.

Our main goals should be to:

constantly clean up and modernize our FE codebase;

define a coding convention and create a consistent look to the code, so everyone would be able to easily understand and maintain it;

and create a consistent look to the code, so everyone would be able to easily understand and maintain it; create and update the documentation (if you don’t document it, it didn’t happen!);

(if you don’t document it, it didn’t happen!); define a maintenance process .

. Actively contribute to the definition of a Design System.

3. How do we cooperate with the other people involved?

When working in an iterative way, it is essential to cooperate constantly with all the figures involved. This is necessary for:

evaluating the design changes step by step according to the needs and / or limits identified.

being all up to date on the statement of work

always being aware of product evolutions. This also benefits test activities, since it prevents that the QA tests would be based on the prototypes produced at the starting time and no longer keeping track of the next occurred variations.

Fighting with the people we are supposed to work with to reach the common goal is counterproductive and it’s always a waste of time and money.

There is plenty of communication and sharing tools out there (Slack, InVision, Zeplin, Confluence) so let’s just give them a try and find the ones that better fit our needs.

About that, I suggest you read this article: Best practices for designer-developer communication.