Sami Surakka

Context

Programming a test on Cambri meant working in two places. Part of the setup happened on the Concept tab and part on the Test tab, and the split reflected how the product had been built, not how a study is designed. It was awkward, but not useless. Some long-standing clients found the first tab helpful because it hid how much work starting a survey from scratch actually is.

For research professionals, including the managed services team, the split was still friction. For everyone else it was a barrier. Cambri's users are not one audience: alongside professionals who know the methodologies, a large share are brand managers and other occasional users who need to run robust research without being researchers. A third group came to the platform specifically for Launch AI, the predictive metric, and they arrive from either background.

Those groups fail differently, but they failed at the same point. New clients regularly could not tell how to structure a test so that it would produce usable results, and customer success and managed services were routinely stepping in to help. Every intervention slowed onboarding, and slow onboarding is where early retention is decided. At worst it cost renewals and new business.

Power users failed the other way: they did not get enough flexibility to run the studies they needed. The job was one surface that did both — a setup that worked out of the box for people who are not researchers, and enough control for professionals — without the resulting surveys becoming unmanageable for respondents, or unmaintainable for the programmers.

There was a sharper version of the problem underneath. If the value of the platform rests on a metric that predicts market success, that prediction depends on the test being structured well in the first place. A programming experience that lets people build a weak study quietly undermines the thing they bought.

Customer success had another gap: roughly 80% of respondents take these surveys on a phone. A preview existed, but it meant clicking through the whole study, and it did not account for the fact that most people would see it on mobile.

Solution

I started from the artefact researchers already use. A brief is a document: objectives, stimuli, questions, structure, read top to bottom. The two-tab model asked people to hold that document in their heads while filling in two disconnected forms. So the direction was to make programming feel like writing the brief rather than translating it.

The editor became a single continuous document. What holds the two ends of the audience together inside it is progressive disclosure, applied as a working principle rather than a pattern. The default path is a template a light user completes by plugging in their stimuli, with the methodological decisions already made correctly on their behalf. That is the less awkward replacement for what the first tab had been doing: hiding the blank page, without splitting the flow in two. The same document then extends into loops, conditional logic, jumps, and piping for professionals who need that control, without those capabilities crowding the surface for people who do not. The limit on that flexibility is the survey that comes out the other end: still finishable for a respondent, still maintainable for the programmers.

Beside the document I added an instant preview that defaults to mobile and updates as the author edits, so they are designing against the surface respondents actually see rather than clicking through a desktop walkthrough after the fact.

Loading…

I also structured the flow, and the product around it, so an AI assistant can sit in it later and write into the same document rather than drive a set of disconnected forms.

I prototyped and iterated the approach with the CTO, testing assumptions as we went rather than validating a finished design. Building the interface in code meant technical constraints showed up while decisions were still open, and it meant the components I made were the components that shipped.

That is also where the UI component library came from. Survey authoring, respondent management, and reporting did not share a common set of components, so interface decisions tended to get remade in each area. I treated the redesign and the library as one piece of work: the visual direction was only useful if it existed as something engineers could build with, so the deliverable had to be the components, not a specification of them. I built the library in code, using Claude Code as the production tool while keeping every design decision my own. Storybook became the place components are documented, reviewed, and agreed on, which moved design review out of static screens and into the actual rendered behaviour. The redesign then rolled out feature area by feature area, built on the library as it matured.

Impact

The survey editor shipped and is in use. A significant amount of the surrounding work remains: more extensive templates, custom templates, a question library, and revising reporting so it matches the new flow. I do not have numbers yet for unaided launch or support load, and I would rather say so than estimate.

The component library is in production use. New feature work is built against it, engineers extend it independently of me, and it will outlast my involvement. That last point is the one I care about most: the goal was infrastructure, not an artifact. The redesigned interface also formed part of what we showed during Cambri's largest deal to date. I contributed the design and the product work; the outcome belongs to a much wider team across engineering, QA, customer success, managed services, revenue operations, marketing, and sales, and I have no way to isolate a design contribution from it.

Role

As Lead Product Designer and Product Manager I owned the design direction for the flow, the product around it, the visual direction and component architecture, and I was the main contributor to the library itself. I worked most closely with the CTO on prototyping, iteration, and testing the approach. Working in the codebase meant my work arrived as pull requests subject to the same review and quality gates as everyone else's, and developers helped me get several of them through. The library is a shared asset with more than one author, and it should be described that way.

Reflection

The two-tab split was the obvious problem. The sharper one was that a default path which looks easy can still produce a weak study, and a weak study quietly undermines the predictive metric the client bought. Holding both audiences in one document meant the light path could not just hide complexity. It had to make the methodological decisions correctly on the user's behalf, then stay out of the way when a professional needed loops, jumps, and piping. The constraint on that depth was the survey that came out the other end: still finishable for a respondent, still maintainable for the programmers.

What I got wrong was the shape of my contributions, not their content. Because I was covering a lot of ground quickly, I bundled work into very large pull requests. That felt efficient from where I was sitting and was expensive for everyone else: large PRs are hard to review, hard to reason about, and hard to roll back. Speed I gained in authoring, I spent again in review, and I spent it out of someone else's budget rather than my own. AI-assisted implementation makes it very easy to produce more change than a team can absorb at once. The constraint stopped being how fast I could build and became how fast the work could be reviewed, integrated, and trusted.