UX Design is an essential part of building digital products, and from a lens-wide perspective, it involves a few simple iterative steps (from idea generation and validation with team members and stakeholders to UI design production and code development, product release, and beyond). It is, however, in software production companies like ours that we’re faced with the difficulties of this kind of interaction, especially in a fast-growing environment, where keeping up with changes and effective communication is required to scale properly.

Starting as a team-of-one in the design department, we’ve expanded to be 5 colleagues (and still growing!) with different backgrounds and responsibilities: from UX, UI, Copywriting, Sprint planning, and more, with an eager spirit to grow as a Design community of practice. We did not only grow in terms of design but our company structure changed as well, evolving the organization into squads that pursue different objectives and need to be aligned with company-wide OKRs.

When thinking small, around a year ago, it made sense to rely on Sketch for the majority of our work, being it easier to control changes and feedback. However, moving forward in terms of scalability and parallel to a worldwide pandemic situation, where remote working became an everyday standard, we were faced with the decision to move our design production from Sketch to Figma.

Making this move, however, did not only have an impact on specific design processes but on our way of thinking in terms of agility, from revision with stakeholders and real-time collaboration with our colleagues, to creating a better-structured design system and managing our version history. This article intends to share some of the changes we experienced in terms of design dynamics, and things we learned along the way.

Starting small 🌱

Like many other software companies and teams, our initial design process revolved around three main programs: Sketch, Zeplin, and Jira, with the first handling all UI solutions, the second bridging the communication between designers and developers (and other key players like stakeholders and marketing), and the later involving our product conception and development sprint with product managers and stakeholders.

With the release of Sketch for Teams, we started to produce design solutions and final mockups remotely, with the added functionality of basic prototyping and file versioning in the cloud. We then proceeded to upload separate screens into Zeplin for review and Jira backlogging. We also took advantage of some of the nice features of Zeplin like file versioning, component library management, and spacing tokens. This approach does not differ from what many companies do, but when scaling up like in our case, saving time is precious. Having faced some of the difficulties like basic prototyping, performance, and wanting to improve our design collaboration, made us look at what other companies were doing in terms of their design workflow. That’s where Figma came into the picture, and seizing it as a mature product alternative at the time, we decided to give it a try and switch.

Making the move: from Sketch to Figma 🎨

There are many detailed articles out there that explain how to go from one tool to the other, and Figma’s documentation on the matter it’s deep enough for more specific details. I intend, however, to share some of the experiences we encountered that may be helpful when making the move.

Structured library tree

Sketch’s library management across files is great, so already having a structured library system was useful. In basic terms, the same configuration was implemented in Figma. Using a base UI from which to grow different stems is certainly the right step towards scalable design growth. Library and design system management is a really powerful feature inside Figma, and a topic to be covered in another article about how we approach this in our company.

File import and handy functionalities

If the project to migrate is big enough, file importing will probably happen, and this is surely a practice that needs fine-tuning afterward. There are some very handy included functionalities in Figma that will aid on this matter, like re-locating components using the “Select all with same instance” command for example, which saves us countless hours even today.

Component re-creation

Importing functionality is very handy but by no means perfect, so you’ll probably end up recreating components, sometimes from the ground-up. This is a necessary step, however, if you want to accommodate for, and take full advantage of, Figma’s component capabilities.

Time and patience

Prepare yourself to spend some research and active time: when deciding to make the transition, you’ll probably need to take the time to do it properly. An inspirational source of ideas will be searching out for real cases on how companies like Spotify, Airbnb, Square, Zoom, and Dropbox, have approached their design workflows.

Smoothing the design process 🍨

Importing files into another software is not that complicated, but mostly a mechanical part of the process. When thinking about scaling a design ecosystem, however, having a defined strategy can aid your way towards being an efficient team, saving you a lot of headaches. Having read some articles on the matter, and on how other companies approach their design process, it was clear that there were many alternatives to take, and from a company standpoint, our reality was different than that of other players, which is normally the case as everyone has its own curated practices.

One of the first things we decided to do is eliminate the middleman, Zeplin. As much as we came to love it, and took advantage of many of its features, the fewer the steps in the process, the lesser the chance of error. We then happen to save time by streamlining our design process revolving around two tools, Figma and Jira. While all agile tasks rely on the last, with our backlog user stories and tasks reviewed by squads, PMs, developers, and stakeholders, all of our design efforts (e.g. ideation, wireframing, mockups, and prototyping) rely on the first.

Concise practices 🏋️‍♂️

Think → Experiment → Deploy

Having a real-time collaborative environment is a beneficial aspect of using Figma, saving time, and opening up a whole lot of possibilities. We faced, however, the difficulty to resolve this new dynamic, coming from a more standard offline/online approach. The initial inertia took us to make our design changes all in one place using pages to separate major areas of a product. After some discussions in our design-dev meetings, though, and some confusion happening during development sprints, we realized the need to separate final decisions with on-going tasks.

In general terms, our process can be divided into three phases. An initial Brainstorming step involves ideation and initial experimentation that can happen anywhere we feel more efficient as designers. This can be anything from a sheet of paper shared later using a photo, or any design software at hand. Digital experimentation then comes into play inside Figma itself in a “Staging environment” which acts as a playground for elements that, if decided, continue to a final “Production environment”. This process gives room to iterations among stages, and a more scalable product design approach.

Lab vs Production

To provide clarity and visual consistency we rely on some emojis to create a visual indication and add some flavor to our files. Our — 🧪 Lab — page works as an experimental sandbox to try out simple and refined ideas before committing to a final design. This is useful for design reviews with colleagues and team members to get on-going feedback. Once a final design is decided for backlog sprint planning, it is moved to a — 🚀 Production — page, where we adjust final details like shared styles, spacings, and additional elements for clarification.

Versioning & Design commits

Similar to our code buddies practices, we rely on Figma’s versioning functionality to save progress steps by making design commits over time in our Production page, indicating major changes. That way, each of us has ownership for pushing design modifications, which can be traced historically if necessary.

Informational and Archived content

Not all content that we produce has to do with the UI, and sometimes we go beyond our scope as UX/UI designers. For this reason, if needed we may use an — ℹ️ Information — page to store details about the project and design artifacts for things like presentational content for other areas of the company and so forth. On the other hand, old files and inspirational elements that we may need for future reference reside on an — 🗂 Archived — page.

Design and backlog integration

Having two design “environments” allows us to work alongside PMs and squad members to place our UIs inside Jira’s tasks and user stories. We normally rely on Figma’s Add-on to include our designs directly on the cards and use separate shared URLs when referencing more than one screen or a section. This dynamic enables us to work on backlog elements that are still in progress, or ready for sprint planning.

So far so good 👍

All in all, the benefits of making the switch have proved to be worth the while and effort. Figma’s approach to real-time collaboration forced us to change our way of thinking and designing, opening the inclusion to other areas in the company even more than before. For us, this is a good thing, since valuable feedback can come from anyone. We also actively take advantage of using comments inside our files and utilize Slack channels to optionally follow-up changes made on projects. These are some of the ways of how we iterate design and content faster as a company.

Working remotely

Remote-life working and shared collaboration did prove to be an active aid for this new pandemic era, with other designers and beloved peers working together. Implementing a conventional file structure to our projects and processes will hopefully improve this, even more. This will enable us to have a system where company colleagues can get an overview of what’s happening from a Design point of view, avoiding unnecessary “discussion noise”.

Design system library management will continue to play an active role of working remotely, aided by cloud document availability and browser-based functionality when needed.

Besides designing, and even though we came to love Figma as a design tool, we leverage many tasks using the mighty Miro, where we can explore diverse ideation and brainstorming solutions with a broader spectrum of colleagues.

What the future holds

Dealing with spacings is still a time-consuming task to ensure the quality and consistency across our UIs, and Zeplin’s visual tokens functionality provided a great aid to this. Having removed it from our workflow, however, implies that we may need to tackle this either through fine-tuning our practices, or custom scripting.

Figma’s possibility not only to design, but to code as well, is something we’re excited about as a Design community, and we’ve set ourselves the objective to create custom plugins as a means of bridging designers and coders.

We consider every feedback as a valuable one, so involving more areas of the company early in the design process is something we’ll work on, aiming to get valuable insights as soon as possible.

Finally, not every idea we come across can be deepened and profoundly tested properly, so exploring and intensifying our prototyping solutions before shipping features will be a key practice to evolve.

Join us ⚡️

Our Product & Tech team is continuously growing and expanding its horizons, with Design being actively an interlaced component. If you like our processes and are interested to know more about us, feel free to check our open positions →. We’re always looking for awesome talents!