Context
About JustRelate
JustRelate builds software for Marketing, Sales, and Service teams. The flagship product, JustRelate Home, is a unified platform that brings together websites, emails, CRM, automation, CPQ, and service processes — all in one place, all aimed at helping companies build better, longer-lasting customer relationships.
The platform is trusted by 4,000+ companies, with a particularly strong presence in the DACH region. Beyond Home, JustRelate offers a family of specialised Builders — tools for creating and managing digital experiences — which together with Home form the complete JustRelate platform.
Problem definition
The challenge wasn't that JustRelate had bad products — quite the opposite. But each product had evolved with a degree of independence, which over time created friction:
- From a user perspective, moving between products felt disconnected. Each had its own design language, interaction patterns, and mental model, creating unnecessary cognitive load.
- From a business perspective, the lack of a clear platform narrative made it harder to position, sell, and communicate the full value of what JustRelate offered.
- From a design perspective, there was no shared infrastructure — no design system, no shared component libraries, no defined processes. Designers were skilled, but working in silos.
Objective
Turn a collection of great products into a coherent platform — and build the design practice that could sustain that vision long-term.
This meant working on three parallel fronts: product vision, team unification, and design operations. Not the easiest starting point, but definitely the most interesting one. ;)
JR Coworker
The agentic marketing OS strategy
The bigger strategic bet — and the one that shaped how I approached both the platform vision and the AI work — is positioning JustRelate as the best agentic marketing OS in the market.
The platform has two distinct layers. Home is the management layer: CRM, DAM, Brands, Campaigns, and other tools for managing data, assets, and marketing strategy. The Builders are the creation layer: Web Builder for websites and apps, Email Builder, Workflow Builder for mailing automations — specialised tools for producing and deploying deliverables. Home is where you manage and plan; Builders are where you make and ship.
The agentic leap happens when AI can move fluidly between those layers: reading context from Home — customer data, brand assets, campaign goals — and instructing the Builders to produce and deploy the right deliverables autonomously. That is what turns a suite of tools into an OS.
JR Coworker as the AI layer
The technical approach behind Coworker is a skill-based architecture: each product surface — whether a Home management tool or a Builder — exposes a set of skills describing what can be done there. Coworker has a corresponding tool for each of those skills. When a user expresses a goal, Coworker reasons over the available tools and calls the right skills in the right sequence, across whichever surfaces it needs.
This makes Coworker inherently extensible: new product surfaces just expose new skills, and Coworker gains new capabilities automatically. It also means the AI is grounded in real platform actions — not generating text about what could happen, but actually doing it: pulling CRM data, drafting in Email Builder, publishing through Workflow Builder, updating a Campaign — all in one go.
Designing this required treating Coworker not as a chatbot bolted onto existing products, but as a first-class platform primitive with its own architecture. The unified platform vision was the prerequisite — you can't build a coherent skill registry if the underlying products don't share a coherent model.
Design team & DesignOps
Building a team, not just managing designers
When I arrived, JustRelate had designers — but not really a design team. People were doing good work, but without a shared practice: no common processes, no shared tools philosophy, no regular design critique or cross-pollination. Building the team meant creating the conditions for that to change.
The goal was to foster a culture of ownership, shared standards, and mutual feedback — where designers felt part of a coherent practice, not just embedded in their respective product areas. This is an ongoing effort, but the shift has been noticeable.
DesignOps from zero
There was essentially no design operations infrastructure when I joined. No defined handoff process, no component libraries, no documented design principles, no onboarding for new designers. Everything was in people's heads or scattered across files.
Building DesignOps from scratch is both daunting and hugely satisfying. I started by identifying the highest-friction points — the places where the lack of process was costing the most time and quality — and worked outward from there:
- Design principles — giving the team a shared language for design decisions and critique.
- Component library foundations — establishing the groundwork for a design system that can grow with the platform.
- Processes and rituals — introducing regular design reviews, design critiques, and clearer handoff workflows with engineering.
- Tooling alignment — standardising the tools the team uses so collaboration doesn't require constant context switching.