Scaling a UI workflow across product, design, and engineering is difficult, especially when your team grows and you’re building two complex SaaS front-ends at once. In this article, Jason shares how we redesigned our entire collaboration process, replaced outdated workflows, and created a scalable, cross-functional system for UI development.

Designing a UI Workflow That Scales Across Teams

Many years ago, when we were a start-up building a single storefront website for ourselves, we faced natural limits to both staffing and technology. Those limits shaped how we worked. Some disciplines stood apart, like product design, while others overlapped, like product and engineering. Often only the people directly involved knew what was happening at any given moment because they were the only ones who needed to know.

Our CEO would request a new or updated feature, a designer would quickly mock up something that looked like a good starting point for a PC screen, and then a front-end engineer would take that design, figure out how it fit with everything else, and apply some version of business logic after shouting a few quick questions across the room. The front-end engineer would then make it all fit and work on a mobile device in the best way they could, and we would move forward. It was lightning fast and very effective, keeping us as the market leader in a highly competitive area.

As we grew over the years, in both the number of colleagues and the number of countries we sell to, we updated our processes. We developed an efficient system for working on the increasingly complex storefront website, but “efficient” still meant that product, design, and engineering often worked in what could be considered as disconnected ways.

While our previous e-commerce workflow was well-suited to our needs back then, the gaps in its processes prevented it from meeting the requirements of building our new SaaS platform.

Why Our Old Way of Working Stopped Scaling

When we began planning our new configurable store application, designed to be used by any telecommunications company in the world, along with the back-office control panel application that would allow them to run their businesses, we immediately realised that our old approaches to building user interfaces would not scale. These new SaaS products contain components that are far more complex than simple e-commerce modules. When combined, the number of interactions grows exponentially, creating the kind of combinatorial complexity that is difficult to control.

The configuration options range from the obvious, such as controlling what components and pages look like in both content and visual theme, to the hidden requirements, such as event tracking and AB testing.

We also realised that introducing configuration options that could affect multiple systems across the entire SaaS store without proper awareness and preparation would create constant bugs and long-term problems.

To achieve these configuration options in a robust and expandable way, we needed to be more deliberate about our front-ends, and we needed to share the same understanding of what all components could do.

That meant much better communication across teams and roles:

• Product management had to communicate their requirements in a way that everyone could understand, as well as in a way that could be referred back to for future projects.
• Designers had to understand the intent behind the requirements and all of the possible configuration options that would arise, along with the impact on the components in the designs.
• Engineers had to understand both the requirements and the thinking behind the design, so that they could ensure the components and features would work as intended while interacting with all the other configurable possibilities.

The Startup Phase

We began by researching into areas where we could improve. Some of the issues we uncovered were:

• Design reviews were sometimes signed off by stakeholders who had no further involvement in the process, and often without engineering input. This meant that we often lost the reasoning behind the decisions that were taken.
• Our design versioning system could not handle changes during development, leading to lost communication and late rework.
• Communication between front-end, back-end, platform, and infrastructure teams was inconsistent, causing misalignment and repeated work.
• Deadlines slipped because estimates relied on guesswork, and features were introduced mid-build without alignment across product, design, and engineering.

This research gave us our goals. We needed a way to build back-end services and front-end applications that could be communicated efficiently across all stakeholders, not just for the duration of the initial MVP projects but also as a reference for future expansion of the system in ways that we cannot necessarily predict yet.

The workflow we created, moving from product management to product design to engineering, allowed us to break the process into phases. This made project life cycles easier to understand and gave us the ability to optimize each phase in a more controlled way. As with front-end code, it is much easier to optimize a single component than to optimize all of them at once.

We took this further by designing the teamwork, not just the org chart, and by shaping an iterative collaboration flow. Product managers, designers, and engineers were grouped into persistent teams aligned to shared outcomes rather than isolated tasks. Instead of handing off work between functions, we brought everyone in early and often.

Forming a Cross-Functional Team

When we approached this problem, we didn’t start with a clean slate. Everyone already had habits, tools, and assumptions shaped by years of working in their own lanes. Forming a real cross-functional team was not about changing job titles or scheduling more meetings. It was about shifting how we thought about shared ownership, effective collaboration, and clear decision-making.

Designers took part in requirement discussions before anything was sketched. Engineers joined design reviews not only to check feasibility but to help shape ideas. Product managers did more than write tickets. They stayed embedded in the conversation as designs evolved and as engineering made trade-offs.

We now have cross-functional reviews, allowing us to plan more efficiently and spot issues in advance.

Refining the Workflow

Collaboration did not become smooth overnight. At first everything took longer. There were more conversations, more disagreements, and less certainty.

But even within the first week the team began to build trust. We learned how to listen to each other’s concerns and work towards a shared understanding.

One of the clearest signs of progress was how often people started using ‘we’ instead of ‘they.’ We stopped thinking in terms of ‘product wants’ or ‘design says’ or ‘engineering needs.’ We started talking like one team solving one problem.

The Component Synchronization Workflow

To make all of this more concrete, let’s look at one example that we worked on: the component synchronization workflow.

This system breaks down larger designs into their individual components, then moves each component through requirements, design, engineering, and release.

It provides templates for requirements, designs, specifications, and the issues needed to make them happen. The result is consistency and clarity, so that our time is spent on creation rather than on deciphering different ways of communicating.

This workflow allows us to introduce new components as well as make incremental, versioned changes. These changes can be as large as a configurable page or as small as a non-configurable base element like a link.

The component synchronization workflow is a lot of steps, but allows for clear documentation and communication.

It’s all in the details… a lot of details!

When we broke down all the steps of this collaboration into the workflow diagram, from requirements to design to specifications to code to documentation, we revealed just how much work goes into producing what many might assume is easy.

Front-end engineers had been carrying much of this burden for years, often without recognition, and this was not only about technical skill. It was detective work: extracting requirements and business rules, reconciling them with whatever logic was already in the code, and negotiating how vague designs should become something real on screen.

By making every step visible, we saw where front-end engineers needed more detailed information to increase their effectiveness, and where those discussions could happen before tickets were written rather than during implementation.

Another big benefit of having a defined process is that we can start to see exactly where the bottlenecks and optimization opportunities are. We’ve already optimized many of these steps since we started using the workflow.

It’s not a waterfall

Building user interfaces is never a straight line. Our first step diagram made that impossible to ignore. Almost every step could loop back to a previous one. In the worst cases, the loop ran all the way from the build process back to the very start of design. Without a clear process that kind of rework can spiral into frustration and wasted time, or worse it never gets done at all.

Above are some of the possible iteration flows during the component synchronization process. We don’t use this visualization in our documentation, it’s easier to just understand that “any step can lead back to any step”.

What’s Next for Our SaaS Front-End Platform?

After all this work, we’ve defined clear workflows for moving from initial requirements to wire-framing and design, through to the specification of configurable modules and components. We’ve also designed, documented, and built many of them, and can now start moving forward into other major parts of the system.

We have already introduced the first page content configuration options, and introduced the system for theming for components, modules, and pages. This is being followed by customer personalization possibilities, and after that we will focus on event tracking and AB testing, which will allow our SaaS clients to see exactly what configuration produced what outcome for their customers.

Taken together, these features, combined with delivering storefront applications to customers in a fast and responsive way, mean that our front-end teams are facing new and exciting challenges while building the platform and the momentum that will push us into the future.

If this kind of collaboration sounds like your kind of challenge, come build with us. We’re always looking for curious engineers, designers, and product thinkers who love solving complex problems together.