No time to read? Here is the summary of the most common reasons that create the gap between designers and developers:
- The "red tape" problem. Lack of collaboration between the design and development team.
- Excessive planning meetings, follow-ups, and reviews that happen due to inefficient processes. The main reason and the ways to avoid them.
- Changes in requirements result in different looks between the finished product and the original mockups. Which then lead to more meetings and revisions.
- Removing the middle man and bringing stakeholders together. Finding ways to make each contributor self-sustainable and independent.
- Recommendations on how to use Figma's projects as process sections to organize, collaborate and document our work.
Step 1: Define the problem
A problem that I faced recently is a puzzle that bureaucrats call "red tape." Red tape is the existence of complex rules and procedures that must be followed to get something done¹. In this case, the red tape is extended to the requirements to get things done in a certain way instead of getting things done most efficiently. To the request to have multiple people approve or comment on work before it's called done, and much more.
Where checks and balances are needed in every large entity to ensure the quality of work and to prevent any side from growing too much or becoming rogue, they should not get in the way of doing what is needed to get things done. Our version of the red tape resulted in a lack of cross-team collaboration and a slow process that affected our delivery.
We approached the problem with two goals in mind:
- To create a process that will keep us in check but also improve collaboration. People had to become excited to work with each other.
- To create a process that will make the end-to-end process faster and a final product better.
Step 2: Removing the first obstacle - The Middleman.
Facilitators are useful in many different aspects of life. When developers are busy discussing the best way to solve a problem, but deadlines keep crawling, we need a manager to put us back on track. When designers can't agree on which art direction to take, they need a facilitator to help them decide. When middle management creates to-do lists for the year but can't agree on which one is the most important, they need a manager to prioritize, kill the dreams, and leave only one idea alive. Ideally, intermediaries remove obstacles and make us better at what we do.
However, facilitating or managing can become a purpose for itself, and then, we have a problem. Traditionally, in other fields such as open market economy, the middlemen are useful when both consumers and manufacturers benefit from their services. They are an obstacle if they are not adding any additional benefits nor solving any existing problems.
One way to solve the middleman problem is to ask yourself three different questions. Those questions are: Who is the owner? Who decides on the business logic and requirements? And who gives a final approval?
Who is the owner?
The answer looks relatively simple. The assigned project owner owns a project. However, what happens when an owner is a manager and not a contributor. Wouldn't it be fair to expect that people doing the work are owning the results? The theory of ownership tells us that an owner does not necessarily have to be the one doing the work. I can own something and hire someone to do the work for me. However, in the design and development teams, everyone is employed, and we cannot apply this theory fully here. So what do we do? Should a product owner be the main contributor? Or should an owner be an employee that communicates with the business owners? A simple question turns out not to be so simple. We can turn our question around and ask: if contributors don't own their work, why would they care for the result? The search for answers seems never-ending, but it drills down to that the owner is the most responsible for the project's success and should bring the most to the table.
Who decides on the business logic and requirements?
I'll be honest; every team I worked on answered differently on this question. However, patterns are evident. In smaller groups, the senior developer or designer is responsible for understanding the business logic and is writing requirements. In the larger teams, that is the domain of the project owner or manager.
The product development process is streamlined the most if the business owner takes care of the business logic and passes it on to the design and development teams. It's even better if it's written and shared in Confluence, Figma, Trello, or another tool of choice, as long as everything is in one place, accessible, easy to find, and reference.
It is best, however, if the requirements themselves are part of the working files. For example, the stakeholders can use Figma, XD or Avocode for documentation, communication, versioning, and much more. We can assemble the whole team in some of those apps with all assets ready and available. It is the easiest and fastest way to keep everyone on the same page.
Who gives a final approval?
The bigger the team, the harder it is to answer this question. Formally, the QA department. Informally, it can be any combination of a project lead, designer, developer, or manager. In reality, the client or a customer! So before launching, we have to get at least three approvals, oftentimes much more.
Once we answered those questions, it easier to make adjustments and remove 'the middleman" (process blockers). Then, we can replace those blockers with an automated system.
Step 3: Change often, change early, but stay on track.
Change is part of every process. Stakeholders should not stop their work when the change happens. Every update should be an integral part of the process, and ideally, only the most complex ones will need in-person meetings. Those ideas represent, of course, an ideal process.
More often than not, changes in requirements lead to more meetings, opinions, and missed deadlines.
The best route I found to deal with changes in requirements is a live collaboration with a stakeholder in the tools that bring us together. Suppose we have access to the same files or a demo website ready and continuously (automatically) updated every time a requirement changes on one side; the other side is aware of it.
A simple workflow could look something like this:
- Trello for project management.
- Figma for idea generation, design, prototyping, collaboration, style guide, and more.
- CodeSandbox for front-end development, collaboration, and UI library.
- Slack for communication.
A simple workflow for designers and developers with just four apps.
We can connect these apps together, for example, by installing Figma plugin in Trello or Slack. And to expand our reach and with apps outside this workflow, for instance, CodeSandbox with GitHub.
Step 4: Putting the product first - product based collaboration.
Organize your work and the work of your team around products, not rigid groups. That means accepting rules that will drive product development instead of slowing it down. It also means we should look for the added value, and if something is not adding value, eliminate it from the process.
A practical example of that approach is a team collaboration in Figma and Storybook. Designers and developers can work together and compare each other's work. Since they work on the same files, they will have to figure out version control. They will not have to figure out who is in which team or navigate through versions of office politics. GitHub makes it easy for developers, and Figma easy for designers. From the start, the product is front and center, and the contributors organize workflow around it.
It might sound that product-driven collaboration takes away individuality and opportunities for individual contributions. That diminishes chances for standing out for all non-technical team members. I like to believe that it makes everyone self-sustainable and independent.
Self-sustainable individuals can do their job without asking for guidance, instructions, passwords, assets, links, examples, which is all part of the workflow and accessible from the apps mentioned above. There is no fishing for files or scratching the head when reading through the requirements. If something should be self-evident, for example, how a component should transition from one state to another, we should not need a meeting to find it out. Independence becomes a by-product of the ability to provide for yourself.
Step 5: Using Figma's projects as process sections
When talking about collaboration between product teams, there is no question about which app to use. Two features that make Figma stand out from the competition are teams and projects.
How to create a team and a project in Figma.
One small adjustment our team had to make when using Figma's free plan was to use projects as process sections. We can apply the same idea within the paid plans with many projects on hand.
The starter plan has a top cap of three projects with an unlimited number of files and artboards within them. With that in mind, we organized those three projects as process sections, namely: playground, features and projects, and specs and patterns.
Figma's projects used as process sections.
The first section - Playground
The playground is open for everyone to experiment and try out new ideas. If you can imagine it, you can test it here and get feedback. This section is the home for all undefined or conceptual work. Teammates can follow each other's ideas and build on top of them.
If it grows and becomes an official project, the owner will move her idea into the "Features and Projects" section.
We are also trying to use the playground for wireframes as a first step in the design process. More yet to come.
The second section - Features and Projects
A project or a feature can find its way to the Features section in two ways:
- Directly - when assigned through the Trello card.
- Coming from the playground. Here we work on all active projects. They are passing through iterations and, once done, will end up in the specifications section.
This process section is the right place where developers can get acquainted with the new ideas and components and where they should join and start asking questions at the same time designers are designing.
The third section - Specifications and patterns
On top of our process are specifications and patterns. Here we store all established and tested designs, and we use them as a single source of truth in all projects. You can find all the assets and design tokens in the files that are stored here. Specs and patterns are also the section developers, and QA testers will reference the most for all work that is not going through the design process.
Some examples of referencing this section are:
- When building a simple widget that will not end up in the design system.
- When making sure spacing fit the established patterns.
- When refactoring a component.
I highly recommend having all completed designs in one place. The main reasons are:
- Speed; it's easy and fast to find the source of truth.
- Documentation; it's easy to reference and know what the final versions are.
- Order; it becomes natural to create new designs only when you really can't use the current ones. And when a designer creates a fresh piece, it is evident if that piece is in check with established rules.
That's it. In this article, I went to the conclusion through the back door. I hope it was fun and useful to read. Please let me know what you think or share your experience below.
Top comments (0)