Strategy, design & growth
Design & product discovery
Product discovery, interface design and design systems — including the specific problem of designing for AI, where output is probabilistic and the interface has to make uncertainty legible rather than hide it.
- Product discovery
- Interface design
- Design systems
- Prototyping
- Designing for AI
- Accessibility
What we build
- Discovery and framing
- The problem, the users, the constraints and what success would look like.
- Clickable prototypes
- The riskiest flow, testable with real users before it is engineered.
- Interface design
- Screens and states — including empty, loading, error and refused.
- Design systems
- Tokens, components and documentation your engineers build from directly.
- Accessibility review
- Contrast, keyboard paths and screen-reader behaviour, checked against WCAG 2.2 AA.
Problems this solves
- Problem
- The interface presents a probabilistic answer as if it were a fact.
- Approach
- Design for uncertainty — citations, confidence, editability and an obvious way to disagree with the system.
- Outcome
- People calibrate their trust correctly, which is what makes them keep using it.
- Problem
- Design and engineering hand work back and forth and neither is happy.
- Approach
- One shared token and component system, with design working in the same primitives the code ships.
- Outcome
- What is designed is what gets built, and review stops being an argument about spacing.
- Problem
- Only the successful path was ever designed.
- Approach
- Specify empty, loading, partial, error and refused states as part of the design, not as engineering leftovers.
- Outcome
- The product behaves properly on the days when things go wrong.
How we approach it
Discover
We watch the work being done before drawing anything. The interesting constraint is usually a step people do outside the software, because the software was never designed for it.
Design
We prototype the uncertain path first — what a model getting it wrong looks like on screen, and how somebody corrects it. Confidence, sources and undo are interface problems.
Engineer
Designs land as tokens and components in the real codebase rather than as a file somebody reinterprets. The design system is the handoff.
Evaluate & harden
Contrast, focus order, keyboard paths and reduced motion are tested in CI, so accessibility is a build failure rather than an audit finding. WCAG 2.2 AA, checked on the built page.
Launch & operate
The system is documented so your team extends it correctly. We would rather ship fewer components that get used than a library people work around.
What we build it with
Contrast as a test rather than a review comment. Every token pair, both themes, on every commit — this site runs exactly this check on itself.
/** Contrast is a test, not a comment in a design review. */
import { contrastRatio } from "@/lib/contrast";
const PAIRS = [
["--text", "--bg"],
["--text-muted", "--surface"],
["--text-accent", "--accent-subtle"],
] as const;
for (const theme of ["light", "dark"] as const) {
for (const [fg, bg] of PAIRS) {
const ratio = contrastRatio(token(fg, theme), token(bg, theme));
// 4.5:1 is the floor for body text at every size we ship.
// The last time this caught something it was a selected
// filter chip at 3.17:1, which looked fine to everyone.
const where = `${fg} on ${bg} in ${theme}`;
expect(ratio, where).toBeGreaterThanOrEqual(4.5);
}
}Questions we get asked
Can we hire you for design without engineering?
Yes. Discovery, interface design and design systems stand on their own. In practice most clients take the engineering too, because a design system that no engineer has built against tends to describe a product rather than produce one.
What is different about designing an AI feature?
The output is probabilistic, sometimes slow and occasionally wrong, and the interface has to make that legible. That means streaming states, citations, confidence, easy correction and an honest way to say it does not know — none of which appear in a conventional design.
Do you do user research?
Enough to make the decision in front of us — interviews, usability testing on a prototype, and analysis of what your existing users already do. We do not run large research programmes; we test the assumption that would be most expensive to get wrong.
Will the design system work with our existing brand?
Yes. The token layer is where a brand lives, so your palette, type and radii sit at the bottom and the components inherit them. If the brand is thin, we can extend it — but we will not quietly redesign your identity inside a product project.
Tell us what you are trying to ship.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.