Improving Our Design Workflow

01. Overview

During product development, I noticed recurring inconsistencies between what was designed in Figma and what eventually appeared in the product. One example was a translation discrepancy where the Indonesian copy did not accurately represent the intended “Processing” status.

Rather than treating each discrepancy as an isolated design or copy issue, I wanted to understand why these problems kept happening. I raised the concern with my Design Manager and initiated an analysis of the workflow across Product Design, UX Writing, Engineering, QA, and Product.

The goal was not to evaluate individual teams, but to identify where information was being lost or misunderstood during the development cycle and provide recommendations that could improve collaboration.

[GANTI INI: deskripsi gambar yang informatif] — From recurring UI issues to the workflow gaps behind them.

02. The Problem

At first glance, the issue appeared to be inconsistent copy or differences between design and implementation.

But after looking at previous projects, I noticed a broader pattern: changes during QA frequently required teams to go back and recheck the Figma design against the developed product. Translation could also introduce inconsistencies when copy was manually translated, sometimes using tools such as Google Translate.

The deeper issue was how information moved between roles.

Product Designers, UX Writers, Product Managers, Engineers, and QA each had their own responsibilities and priorities. However, there was no clearly defined moment or communication mechanism that consistently connected their work.

03. The Approach

I started by speaking individually with the people involved in the development cycle:

QA Engineer Lead
UX Writer
Mobile Technical Lead
Product Manager
Product Designer

Each conversation lasted approximately 30 – 60 minutes.

Rather than asking only what went wrong, I focused on understanding how each role actually worked: what information they received, when they received it, what they produced, and where they needed to communicate with another role.

From these conversations, I documented the different workflows and looked for points where information could become unclear or disconnected.

04. The Improvement

Turning findings into practical workflow recommendations

The analysis showed that the improvement opportunity was not about introducing another tool. It was about creating clearer moments of communication throughout the development process.

Based on the mapped gaps, I proposed several improvements.

#01

Involve UX Writing earlier

UX Writers can start preparing copy once the initiative is sufficiently clear, even before the final UI is ready. This gives them time to benchmark existing products, explore terminology, and prepare copy rather than treating writing as a final stage task.

#02

Discuss edge cases earlier

Product Designers can proactively discuss edge cases with QA Engineers during the design stage, allowing potential scenarios to be considered before development rather than discovered during QA.

#03

Communicate design changes explicitly

Any changes to the design should be communicated through the team’s Slack channel so that relevant roles have a shared reference rather than relying on individual conversations.

#04

Standardize Figma structure

I recommended that Product Designers use a consistent page structure in Figma. The goal was to make designs easier for QA and Engineering to navigate and reduce ambiguity when reviewing the source of truth. This recommendation was also documented in the original project.

What I implemented

This distinction is important for your credibility.

I personally implemented the standardized Figma structure with support from my Design Manager. Other designers were still adapting to the format when organizational changes and layoffs disrupted further adoption.

So I would write:

This avoids overstating the scale of implementation.

05. Outcome

The recommendations were shared with the relevant leads as input for broader cross functional discussion. The original project records that the recommendations were subsequently applied across three Ula projects.

I also applied the standardized Figma structure to my own work, helping reduce the possibility of differences between the design source and the UI eventually implemented by Software Engineers.

However, I could not measure team-wide adoption or quantify improvements in development time. Organizational changes and layoffs happened soon after, limiting the opportunity to continue tracking the initiative.

That limitation is worth stating explicitly. It shows that you understand the difference between a recommendation, an implementation, and a measured organizational outcome.

06. Reflection

The biggest lesson for me was that operational problems are often caused not by a lack of skill, but by a lack of communication.

When everyone is focused on completing their own responsibilities, it is easy to forget that the next person may be working with different constraints, information, or assumptions. Taking the time to understand how each role works helped me see the problem from a system perspective rather than blaming the final output.

Want to discuss this project?

I’d love to talk through the process, the decisions, and the lessons learned.