case-file-organization

Organization and reduction of development errors

Homer Real Estate Partnerships

In this case study I show how a file organization process helped us to decrease development errors and facilitated access among different teams.

Problems

In its early days, Homer was just a solution that connected realtors to build partnerships.

Over the years the project became more and more robust and added several solutions to make the realtor's life easier.

Consequently, the team itself grew and we started to have more developers, new squads, new designers.

We started to have several implementation problems in our projects. Often basic errors such as button behavior, layout errors, etc. Errors that ended up impacting the combined delivery of the sprints.

These problems were somewhat easier to be solved in the beginning because we had a lean team working in person, the access to doubt was literally on the chair next to us. With the arrival of the pandemic in 2020 the team started working remotely and we started having people in the team from different regions of the country.

Our team also had a lot of difficulty finding out what the trackings of each implementation were, sometimes impacting a wrong reading of performance.

Main Objective

The big goal was to eliminate as many of the implementation errors as possible in all aspects, layout behaviors, trackings, etc. Finding a better organization than the current one.

Step 1 Discover

TEAM INTERVIEWS

We talked to several internal members to better understand the needs and specificities of each team.

EXTERNAL INTERVIEWS

We also talked to friends from other companies to better understand how the organization process worked in their company. And to understand what made sense to bring as an improvement to our team.

BENCHMARKS

We did a benchmark to understand a little bit about the organization of other companies and what material was shared about it that could help us.

Step 2 Define

After analyzing all the material we collected, we highlighted the main points and correlated them with our problems. Separating only what made sense for our day to day life. Many external problems did not fit our reality.

Step 3 Ideate

Based on the collected materials, we opted for some definitions:

JIRA

We realized that many of the questions were taken by slack in a private way or in unofficial channels (WhatsApp). As we use JIRA to organize the tech team and sprints, we decided that each and every question should be described in its respective task in JIRA, so we would have documented, and we could also better measure how many errors arose during the sprint.

FIGMA

This is where we made the main changes. We saw several opportunities for improvement through the surveys and remodeled the structure as follows:

PROJECT SECTIONS

The first change was in the organization of the project and files. Since tasks and goals usually came up by solution, we decided to have a dedicated section for each solution we have.

In addition we created some sections that would be useful for both us designers and other team members.An example: We created an ON STORE section in which we keep a file with all the screenshots of our app/web in an updated form.

The idea is to have a faithful version of the app as it is in the store. With this, the marketing team could access these files if they wanted to get an image of a specific screen to use in their materials.

We documented the whole structure in Confluence so that future members can consult and follow the same pattern.

FILE NAMING

In addition to each file being in its respective section, we standardized the naming of the files in a way that made it easy for everyone on the team to consult them.

We made a simple "name generator" to facilitate the creation on a daily basis.

ORGANIZATION IN THE FIGMA ARCHIVE

Using the figma pages, we organize different sections according to the stages of the project and their respective platform. If a project is broken into stages, we place its respective version within the respective section (example. [V1] - Android).

Handoff =====
Here we list all screens and their possible variables in the project without repetition, just listed sequentially.

Behaviors =====
Here we detail all the possible behaviors and variables of the project elements.

Flows =====
Here we detail all the possible flows organizing the screens and their variables.

Trackings =====
Here we enter all the information regarding the project's tracking.

Design =====Here we keep everything that was scribbled down before finalizing the project.

Research =====
Here we use to put mainly benchmarks and other types of research while the project is in this stage. It is not a documentation but more like a place for quick reference. For research documentation we use confluence.

ABOUT TRACKING

Here was one of the main organization changes, previously all trackings were done in a spreadsheet. Bringing it to figma we were able to visually expose each tracking in each element, so that the developer can immediately nomenclature the trackings without resorting to external files.

BEHAVIORS

Here we detailed each element's behavior and how we wanted it to work. All of this was presented in planning meetings, but being separated in the figma, the developer who had a future question could make this query in the file itself.We also put here variables for elements like cards, menus, etc.

Results

The results after the implementation of this new organization exceeded our expectations, we were able to reduce the recurrent errors in the sprints by 80%.

The organization was highly praised by members of other teams and part of this organization was used to reformulate the organization of other Homer teams

All the organization of files and organization by solutions facilitated consultation among the teams:

• The data team started to consult the files by itself to access the nomenclature of the trackings.

• The Marketing team gained autonomy to export screen layouts and use them in their strategies.