Julian Juillerat
Work  /  spec27
AI evals · Via North · 2025

The redesign that began by correcting the product's model of itself.

End-to-end

Spec27 tells teams whether their AI agents hold under pressure — powerful software, and nearly unusable. Over two phases with Via North I led the redesign end to end. The move that made the rest work wasn't restyling screens; it was correcting how the product understood its own parts.

Role
Design lead, end-to-end
Team
Led a dev + designer
Sector
AI / deep-tech
Engagement
Sprint → full redesign
Status
In production · evolving
The problem

Built by engineers, for engineers — in a domain with no playbook to copy.

Tangled navigation, long flows, no onboarding, no empty states. None of it was cosmetic — restyling couldn't touch it, because the confusion was structural. It lived in what the product thought its own parts were.

As we found it
The original build
Shipped
The shipped redesign
Same product, one project's overview — before and after. Blue links and a flat rail of look-alike items on the left; one clear primary action, a coverage view, and real hierarchy on the right. Click to enlarge.
The pivotal move · a confused build, worked back to a model

The broken navigation was a symptom. Correct the product's model of itself, and navigation follows.

When I arrived, the product fought you. Result views and stored resources shared one rail; the counts at the top of a page doubled as links; and the same names — evals, specs, agents, datasets, judges — sat again at the org level, so leaving a project showed you the same list at a different scope. So I stopped drawing screens, worked out what each part actually is, and let the navigation fall out of the model.

01  What we found 02  Reading each element 03  The model 04  The navigation that followed
01 — What we found

The same names, in two scopes, meaning two things.

Inside a project, one rail mixed result views with a flat drawer of assets. Step outside the project and almost the same list reappeared at the org level. Five names lived in both places at once — and nothing told you which scope you were in.

Level 1 · Organization — Safe Intelligence
Evals
Specifications
Agents
Datasets
Judges
Error logs
Registry
Projects
open a project
Level 2 · Inside a project
This project
Overview
Eval robustness
Agent robustness
Assets
Evals
Specs
Agents
Datasets
Judges
Settings
Coral — one name, repeated across scopes
And the page header doubled as navigation
1 Agents 0 Secrets 7 Datasets 12 Specifications 5 Evals

Click a count and you dropped into a list — with no way to tell a result from the resource it came from.

02 — Reading each element

Six names. Only two real resources.

With no reference product to lean on, I classified each name by how the product actually uses it. Four of the six aren't entities — they're parts of the contract, properties of the agent, references, or an action you run.

What it was
Really a…
Why
datasets
Part
The entries inside a spec (primary + adversarial). Part of the contract.
judges
Reference
A versioned resource the spec references. The user doesn't even pick it directly.
secrets
Property
A property of the agent.
evals
Action
The action (agent × spec) that produces results. You create them to run, not to accumulate.
agents
Entity
A real top-level resource — the subject being tested.
specifications
Entity
A real top-level resource — the contract — and it contains several of the above.

The coral tag marks the tension in the model: an eval is an action, not a resource. But in client reviews, dropping "evals" from the sidebar lost the product's central concept — so it stayed, as the one page where the model is visible. A client call, and the right one.

03 — The model

One entity sits above the rest — the evaluation.

An evaluation is the outcome — what a project exists to produce. It isn't a thing you store; it's what one agent and one specification make together. I pinned the model down with the engineer who built it: only two of the six names are real, top-level resources — everything the old shelf listed as their peer is really a part of a specification.

The evaluation · the outcome
What a project exists to produce
derived — never stored
one agent × one specification
Agent
What's tested
A real top-level resource — nothing inside it.
×
Specification versionable contract
The contract — a real top-level resource
…and it contains
Entries — its datasets, primary + adversarial
← datasets
Schema — the shape of an entry
Knowledge — agent + judging context
Judge — method + judge
← judges
Settings — configuration

Datasets and judges fold into the specification; secrets is a property of the agent; the eval itself is an action. None were resources of their own — so none earned a place in the nav beside Agents and Specifications.

04 — The navigation that followed

With two resources, the navigation almost drew itself.

Two scopes, cleanly split. At the org level: Home for every project — the global error logs became a tab there — and Explore, the org-wide catalog that used to be the registry. Inside a project: the views and the two resources, nothing borrowed from the org level. Help — a floating button in the old product's bottom corner — moved into the sidebar. And “evals” became the one page where the model is visible.

New nav · org level
Home
ProjectsActivityError logs
Explore
Help
Documentation
Support
New nav · inside a project
This project
Overview
Evalsthe matrix
Results3 robustness views
Specifications
Agents
Settings
Evals — one shape, repeated everywhere
The same pairing surfaces across the product — one specification, measured across a set of agents.
Matrix coverage1 spec × 2 agents · 2 of 2 cells run
OpenAI ChatKit RAG AWS Bedrock RAG Natural & error variations
pass failone cell = one agent × this spec
The same matrix, three places in the product
Overviewthe project counts
Evals listspec × N agents, per row
Each evalthe coverage grid above

Before, nothing on screen said what the system was. Now the same agents × specs matrix reads on the overview, down the evals list, and inside every eval — so the model is legible wherever you look.

What followed from the corrected model

With the model right, the rest was execution.

Most of what came next was disciplined execution on a foundation that finally made sense: flows rebuilt end to end, navigation that mirrored the two real resources, and onboarding and empty states where there had been none.

Navigation & flows
Rebuilt on the two real resources, end to end.
Onboarding & empty states
Designed where there were none.
A design system
Built from scratch, governed as the source of truth.
A light rebrand
Logo, wordmark, palette, type, motion.
A launch landing page
Shipped in about a week.

The same overview, at every stage of the engagement.

Click any frame to enlarge
00Original build
Original build
01Structural pass
Phase 1 structural pass
02Rebrand lands
Phase 2 rebrand
03Shipped
Shipped direction
The rebrand kept it light on purpose — enough to give every rebuilt screen a fixed foundation, not a detour. Safe Intelligence carries the credibility; spec27 gets its own precise-with-attitude voice, set out in the spec27 motion language ↗.
How I worked

Two phases: quick wins first, then the full redesign.

A close deadline split the job in two: first, every quick win the date allowed — then six to seven weeks to do the full redesign properly.

Phase 01
A few weeks
Quick wins, first conceptualisation

Three core screens plus navigation, no room for the standard design→present→validate→revise cycle: assumptions explicit, tight rounds, rationale annotated in Figma for async sign-off. What shipped was the product's first conceptualisation — a UI the full redesign would replace.

Rebrand the fixed base
Phase 02
6–7 weeks
The full redesign

Run as a program: every rebuilt screen inherited the new base, then flows, nav, screens and a design system — phased, with checkpoints, buffers and a weekly cadence. Design and build ran in parallel; the plan kept parallel from becoming chaos.

AI in the loop

Working sessions with the engineers off the back of each discovery, AI to explore concepts fast — never to replace the thinking. The design system stayed the single reference; nothing invented.

Deciding with the client

Model questions were settled on something clickable, not in the abstract. Calls made ahead of sign-off, kept cheap to reverse — and always flagged: decided, or still assumed.

The sprint board
The sprint board — rounds across the core screens, every decision annotated.
Outcomes

The whole product — redesigned end to end, shipped in two weeks.

This wasn't one screen or one flow — it was the two-resource model, every rebuilt flow, the onboarding and empty states it never had, on a governed component system. And because I handed engineering the build as working HTML — tokens, components and states, not comps to reinterpret — the full rebuild shipped in the last two weeks of an eight-week project, in time for a major relaunch. It's live at staging.spec27.ai.

Implementation
~2weeks
full rebuild · HTML handoff
Relaunch
500+leads
first real cohort · not yet activation
Set-up flow
30–407steps
the 0→1 flow
Product surface
−60%pages
fewer screens
First run
Guided
onboarding it never had
Timeline and leads from the engagement; step counts from the project-creation audit; pages and onboarding from the shipped build. Product-usage analytics weren't available for this write-up.
Validation · the diagnosis, confirmed

The problem the redesign targeted — confirmed after launch.

The whole rebuild rested on one diagnosis: the product dropped users into an editor without modelling what to do with it — no onboarding, no obvious first move. After launch, the team ran its own analysis of early churned sign-ups, reconstructing their journeys from production traces. It surfaced the same gap independently — new users moving through the interface without ever reaching the core action the product exists for. The work set out to fix exactly that, and the client's own post-launch read confirmed it was the right problem to solve.

No before/after usage to claim yet — fewer than ten people could use the product before the rebuild, so the relaunch cohort is the first real one. Conversion instrumentation on the rebuilt flows is being defined now; activation metrics follow from there. What's already proven stands on its own: the structural fix, the step and surface reductions, and a diagnosis the client's own data backed.

What the client said
“The UI was an absolute mess, and your guidance was instrumental in making it coherent.”— The client's engineer
The CEO credited the team for staying focused at the right level — solving the real problem rather than pushing a grand redesign.— The client's CEO
Interactive · live build

Click through the actual build.

The build itself, fully navigable: create a project, open the specification editor, run an eval.

spec27.app
Live
spec27 home — the shipped build
Launch the live prototype
Full navigable build · best on desktop
Click inside to navigate · best on desktop
The design system · rules before parts

The system's first job was a primary action you couldn't miss.

The audit named the root problem: no primary-action hierarchy. The one correct next move was styled like every secondary control beside it, so users stalled. The system is defined by its rules before its parts — a handful of enforced decisions that make the right action obvious on every screen.

Rule 01 · the fix
One primary action per view.

Neutral at rest, accent on press. The next step is never ambiguous.

Rule 02
Exactly one accent.

Purple marks the primary path and nothing else. It always means “go here”.

Rule 03
Status lives in the dot.

State is a small coloured dot, never a whole coloured component — dense data stays calm.

Rule 04
One height, one scale.

36px controls and a fixed radius scale. Buttons, inputs and selects line up without a decision.

Built from scratch and handed to engineering as the spec — tokens, rules and states — so the build stayed consistent without me in every ticket. The full system, dense-data components included, lives in the live build ↑, or browse it directly as the full component library ↗.
Next project
Caja Ingenieros — design inside a 7-year system
HomeWorkAbout
Barcelona · © 2026