Scaling a UI workflow across product, design, and engineering is difficult, especially when your team grows and you are building multiple 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.
Over 20 years ago we started building a telco-specific commerce platform from scratch, because generic commerce solutions were getting in the way of the customer experience telcos needed. Together with our landmark customer we learned fast by solving real telecom product and journey complexity with a lean team and limited tooling. 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.
A stakeholder 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 our commerce SaaS platform scaled across markets and use cases, our customer facing commerce application evolved from single websites into a configurable channel layer that needed to support many variations. We improved our delivery process to keep up with that complexity, but “efficient ” still meant that product, design, and engineering often worked in what could be considered disconnected ways.
The real shift happened when we moved from building an implementation for our landmark customer to running the same commerce product for multiple telcos, markets, and channels. Over the years that work grew into a telco-focused commerce SaaS that proves itself every day in real customer journeys. As we moved from building for one environment to supporting multiple telcos, markets, and channels, we had to make both the customer facing application and the back-office control panel configurable, while still keeping existing core systems intact.
Serving multiple telcos also introduced a powerful new feedback loop. With clients across different markets and operating models we now receive far more external input on journeys, edge cases, and priorities. This helps us validate what should be standardized in the platform and where configurability creates the most value.
The configuration options range from the obvious, such as controlling what components show up where, all the way to the hidden requirements, such as event tracking and A/B testing.
We also realised that introducing configuration options that could affect multiple systems without alignment and preparation would create constant bugs and long term problems.
To achieve these configuration options in a robust and expandable way we needed everyone to share the same understanding of what all components could do.
That meant much better communication across teams and roles:
We began by researching areas where we could improve. Some of the issues we found looked like this:
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 stakeholders, not just for an initial MVP, but also as a reference for future expansions we cannot necessarily predict yet.
The workflow we created, moving from product management to product design to engineering, breaks the process into phases. That made project life cycles easier to understand and gave us a practical way to improve one part at a time. Just like with UI components, it is 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. Instead of handing off work between functions, we brought everyone in early and often.
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.
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.
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.
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.
Building user interfaces is never a straight line. Our first step diagram made that impossible to ignore. Almost every step can loop back to a previous step. 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.
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. Our platform already provides a broad set of capabilities for building and running high-performing telco commerce channels. Within that foundation we have strong support for page content configuration, theming across components, modules, and pages, customer personalization, and capabilities for event tracking and A/B testing.
Our focus now is on making these capabilities significantly easier to configure and operate at scale. So SaaS clients can move faster, iterate more confidently, and optimize customer journeys with less effort and fewer dependencies. Taken together, this is about enriching and streamlining what is already in place: improving usability, deepening configuration where it matters, and making insights and optimization more accessible. We are especially excited that telcos around the world can now benefit more easily from our world-class channels, and configure them to match their brand, journeys, and markets in the way that works best for them.