Design-to-dev: improving the delivery process between teams

How to open a channel of communication in order to build a cohesive product delivering value to users?

by Daniel Granero and Carolina Barbosa Russi, from Sensorama’s Design team

Like everything else in life, digital projects have a beginning, middle, and end. It is about one specific part of this process that we want to comment on in this article: the delivery of interfaces to the development team.

In July 2020, we faced the challenge of redesigning a solution for a large beverage company. An internal system which supports the entire process of negotiations with customers.

In initiatives like this, there is a time that UX/UI Designers need to deliver the interfaces to the development team that will program the solution. That’s part of the natural course of digital projects, whether they are in a technology company, a startup, or even a consulting firm like ours. This is always a moment of attention, because everything that the design team has created (which goes far beyond just screens) must be communicated accurately to guarantee that users have the best possible experience. That’s why it is so important to structure this delivery in the best way possible.

We are happy to say that everything went well. We followed Sensorama’s work methodology (understand-define-perform-validate) and managed to design the planned modules on time. After going through a moment of some very hectic deliveries, when realizing that some doubts were being raised about the behaviors of some components of the system, we decided to take the time to review our delivery process with the development team.

As part of our design DNA, we started by trying to understand the problem before we started thinking about possible solutions. The first step was to bring the development team together for a conversation (in this case, they were our users) to identify what the problems were (or what the pain points were, as we usually call them) and what they were missing during the transition to the next step. The most common pain points were the absence of extreme scenarios (those that appear when the screen is empty, or when there is an excess of content), predictions and error messages, the absence of a more elaborate description or demonstration of some interactions and status variations of components.

After finding out what the problems were in the delivery flow, we went after references and good practices, benchmarking and investigating how this process works in other environments. We talked to designers who work in other companies to better understand how they deal with similar situations.

Thus, we discovered, that in the rush of deliveries, important points were being overlooked, such as how it is fundamental to have good communication between teams, with open and frequent conversations; the importance of keeping files organized, with standardized nomenclatures and orderly screens; also on the development and presentation of flows, so that the development team can better understand the paths of the system and complement them during the creation of the stories.

With that, we finally arrived at the stage of carrying out and implementing the solutions we envisioned.

First, we start by organizing our delivery rituals. At the beginning of every sprint, we present everything that was designed in that period for the entire team of developers and their respective objectives, flows, feedbacks, and interactions.

In the previous process, we presented to only two analysts who handed everything on to the rest of their team, organizing the stories of the tasks and calculating the delivery times. With this change we dispelled communication failures and brought teams closer together. We also organized a weekly meeting so that developers can answer questions and point out possible technical obstacles, which also allowed us to analyze what was being programmed and avoid corrections when the time to deliver arrived. At the end of each Sprint it was then the development team’s turn to present to us what has been developed. We followed what has already been implemented and in addition we could plan more tests with users.

“Delivery index” with links to the screens developed

With an improved communication, it was time to go to the documentation. Within our archives we have implemented some actions to facilitate this transition:

Here at Senso, our favorite interface design tool is Figma. It greatly facilitates our design process, as we can create flows, wireframes, prototypes and even raise the level of the interfaces until the layouts. It’s also through Figma that we transfer files to the development team.

As all the steps we design for the projects are grouped in one place communication is facilitated, but with so many people interacting in the same file it is very easy for it to become confused and disconnected. During our restructuring of the delivery process, we saw the value of having a well-organized and standardized file. We have defined a naming standard for the screens and for the elements present in the style guide. We also relocate screens on pages with ratings according to their function.

This helped the development team to know where to find the interface components and locate them.

How we organize our files in Figma

As Steve Jobs said, “Design is not just what it looks like and feels like. Design is how it works”. So communicating the system’s behaviors well, with all its microinteractions, feedbacks, initial use cases, assets and extremes is fundamental.

We then decided to add a section of explanatory comments to each delivery on what behaviors are expected for the elements that make up the screen. We comment on the limit of characters allowed within a space for filling in or what options are available in the selection field, making the alternatives that the user will have to interact in the interface more understandable.

Thus, developers have visibility into the complexity of each element that makes up the interface that they will have to program, which improves the projection of the delivery time and avoids future corrections.

Example of explanatory comment of system behaviour

Before we reviewed the delivery process, our style guide was stagnant, with the original components that we created at the beginning of the project to design the first screens. A good part of it was out of date.

After our initiative to change the delivery process, we decided to reorganize and update the style guide, with greater specifications and predictions of different behaviors of the components. Thus, the development team can have visibility of all the states of the screen elements. This helped them to minimize errors and stimulated the modular development of the components.

We already produced high-fidelity prototypes before we reviewed the delivery process, but we only did it with screens that went through the validation stage with users in usability tests. We realized that to improve our deliveries and facilitate the creation of flows and stories for the development team, prototyping the next screens to be programmed and their micro-interactions could help.

We decided to do this before validating with users so the team will have full visibility of the viable paths through the system and what interactions are possible.

Each blue connection represents an interaction that the user can make on the system

With all the lessons learned, we conclude that the basis of a promising team at the end of the day is simple and clear communication. Having an open channel for exchanging feedback and interaction in order to jointly build a cohesive product that delivers value to users. For the time being, the feedback was all positive: there was an improvement in communication with the developers and the validations of the quality team were also benefited.

We deliver a product more adherent to the one intended by the design team, which delivers more value to the business team and solves the pain points of end users.

We took important steps. Like everything else in design, we are sure that nothing will ever be truly ready. With that in mind, we are implementing this process in other projects to assess the effects and constantly evolve it.

Have you had any experience similar to ours? Tell us in the comment section.

*Este artigo também está disponível em português, acesse aqui para conferir. :)

We are a UX Design & Service Design team who wants to make business human again. We are inspired by people.