Bridging design and implementation

01

Overview

Over six years I worked both on the Glow platform itself and later as a product designer building solutions on top of it.

Glow was WiseTech’s low-code platform for creating operational web applications. Product teams used Platform Builder, form flows, business rules, security models, release environments, and testing infrastructure to create customer-facing portals without building every experience from scratch.

That experience gave me a rare perspective. I understood not only how the platform was designed, but also what it was like to rely on it every day to deliver real products.

As I transitioned from the Glow team into HRM, I became a bridge between platform capabilities, product requirements, and implementation realities. Over time I became a go-to resource for designers and product teams navigating the complexity of the ecosystem, helping others make informed design decisions within the platform’s constraints.

02

Context

Modern designers often work with design systems, but Glow was significantly more than a design system.

It was an entire product-development ecosystem.

Building a portal required understanding a wide range of interconnected concepts: visual design configuration, form-flow orchestration, business rules and conditional logic, data modelling, security and permissions, release management, testing environments, and deployment workflows.

Each area had its own concepts, terminology, and configuration model. While this architecture enabled rapid development at scale, it also introduced significant complexity for teams building products on top of it.

Understanding how all the pieces fit together was often as important as understanding the user experience itself.

03

Phase One: Designing the Platform

My career at WiseTech began on the Glow team, where I worked on the platform used by product teams across the business.

This gave me a deep understanding of why the platform was structured the way it was, the trade-offs behind platform decisions, how visual designs translated into runtime experiences, the relationship between business rules, workflows, and interfaces, and the technical constraints product teams would eventually encounter.

At the time, that knowledge was focused on the platform itself. I understood how the system worked, but I had not yet experienced what it felt like to build products with it.

04

Phase Two: Becoming a Product Team Customer

In 2019 I became an embedded designer in the Human Resources Management team.

For the first time, I became a customer of the platform I had previously helped design.

Rather than thinking about platform capabilities in isolation, I now had to use them to solve real business problems.

That shift exposed an entirely different perspective. I experienced the strengths of the platform, the areas where workflows felt cumbersome, the practical limitations of certain configuration models, and the challenges faced by designers and developers trying to deliver products efficiently.

Because I already understood the underlying architecture, I could navigate complexity that many teams struggled with. That meant less time fighting the platform and more time finding effective implementation patterns.

05

Building Expertise Through Practice

Unlike many product designers, my role extended beyond producing concepts and handing them to engineering teams.

I regularly worked directly within Platform Builder, configuring experiences and validating implementation approaches.

While initial concepts were often explored through wireframes and collaborative discussions, many design decisions were refined through hands-on implementation.

This close proximity to delivery accelerated learning and exposed trade-offs that would have been difficult to identify through static design artefacts alone.

Over time I developed a practical understanding of how to balance user needs, business requirements, platform constraints, and engineering effort within a highly specialised environment.

06

Becoming a Go-To Resource

As Glow adoption increased, more product teams began building increasingly sophisticated portals.

Because of my experience on both the platform and product sides, I was frequently consulted by designers and product teams looking for guidance.

Many implementation decisions were constrained by architectural realities that were not immediately obvious to newcomers.

Having already explored many of these challenges within HRM, I could help teams understand which approaches were feasible, which trade-offs existed, which implementation patterns worked well, and where platform limitations might influence design decisions.

That allowed teams to move faster and make more informed decisions without repeating the same discovery process.

07

Knowledge Sharing at Scale

As I became increasingly involved in both the Glow platform and HRM product teams, I also helped drive a broader knowledge-sharing initiative aimed at improving collaboration across the organisation.

Part of this work involved developing and presenting a business case to senior leadership that ultimately led to the adoption of Stack Overflow for Teams across WiseTech.

Once rolled out, the platform significantly reduced knowledge silos between product teams navigating the complexity of Glow.

The platform created a central place for product teams to ask implementation questions, share solutions, and document patterns. I became an active contributor, both seeking advice and helping others solve problems.

These conversations often revealed gaps between how the platform was intended to be used and how teams were attempting to use it in practice. The resulting feedback loop improved platform understanding across the organisation while also surfacing opportunities for future platform enhancements.

08

Impact

While the outcomes were distributed across many projects rather than a single feature release, the impact was significant.

• Faster decision making for product teams
• Reduced implementation uncertainty
• Reusable design and implementation patterns
• Greater confidence working within the platform
• Feedback grounded in real-world product delivery
• Improved understanding of emerging use cases
• A systems-level understanding of enterprise product delivery
• The ability to bridge design strategy and implementation reality

09

Reflection

The most valuable lesson from this experience was that great product design does not happen in isolation from implementation.

Working first on the platform and then on products built with that platform gave me an unusually complete understanding of the product-development lifecycle.

I learned that influence is not always measured by the screens you design. Sometimes it comes from helping teams navigate complexity, sharing knowledge, and creating clarity in environments where there are rarely simple answers.

That experience continues to shape how I approach product design today, balancing user needs, business goals, technical constraints, and organisational realities to create solutions that are both desirable and achievable.