Case study · Systems · Research-led prioritisation

Seven builders,
one system

Seven form builders doing one job, and no single owner. I framed the problem, ran the research, designed the system, and changed the roadmap with what I found.

CompanyKeap, acquired by Thryv

RoleSole designer · end to end

Research2 usability studies · survey n=25

Timeframe2024 to 2026

FocusSystems · Prioritisation · Influence

Product screens, captured from demo accounts.

01 · Why this work

Seven ways to build a form, and users still left

Four live form products and three legacy ones, each with its own UX, spread across four owning teams. Mine owned four of them. Three other teams owned one each. Every improvement got rebuilt per builder or shipped to just one. Nobody owned the whole problem because it was not any one team’s. I took it on.

Users could not tell them apart

The naming was the product’s vocabulary, not theirs. Legacy migration stalled for the same reason: with three modern builders, there was no obvious one to move to.

So they built forms elsewhere

Four rival form tools showed up in our own survey. One general-purpose tool alone was named by a quarter of respondents.

One form had got worse

I pulled every form’s measured score before drawing anything. Only one hit its target, and the most-used form scored lower after a rebuild than before it.

I thought web forms ARE public forms. Do not know the difference.Survey respondent

02 · My role

End-to-end design leadership

I was the only designer on the initiative. I framed it, ran the research, designed it, sold it and oversaw delivery.

Connected six years of orphaned research

Studies going back to 2020 each answered one question and then went quiet. Nobody had put them next to each other. Five prior studies are the reason I could argue this was structural and not a fresh opinion.

Ran the primary research

A 25-person survey with two researchers, a nine-platform competitor audit, a prioritisation workshop, and I designed both usability studies.

Defined the north star and phasing

Parity first, consolidation second, appointments and payments after. Checkout belonged to another team, so the phasing was also a buy-in problem. I had to win that team before I could design into their surface.

Argued against the full rebuild

A rebuild was the assumed answer. I showed the data models were already sound and the fragmentation was a surface problem: twelve-plus months and regression risk for marginal value. Winning that framing set the scope of everything after.

Timeline of nine research studies from 2020 to 2026, with the four the designer ran highlighted — I did not start this research. I connected it. Five earlier studies each answered one question and went quiet; putting them beside my four is what let me argue the problem was structural, not an opinion.

03 · The reframe

Ask what the form is for

Seven products became one builder and four use cases. The categorisation is not cosmetic: it is what tells the system where a form is allowed to appear. Both vocabularies appear on purpose: the use case leads, the legacy name follows in brackets, so existing users can still find what they know.

Create form screen asking What form do you want to create, with four cards: Marketing (Public), Management (Internal), Payment (Checkout) and Appointment — The picker that replaced seven product names. The use case leads and the legacy name follows in brackets, so the categorisation teaches the new model without stranding anyone who knew the old one.

Consolidation is also what made AI generation possible. One builder means one generation target, so a model can emit a complete form with full feature support, which no fragmented system could have offered.

04 · Testing

Round one went badly, and that was useful

Round one · 7 participants

Every participant hit friction. Seven of seven could not find how to add a step; six of seven stumbled on inherited taxonomy. The live side-by-side preview was named most often as the thing that built trust.

Round two · 8 participants

Manual creation scored a perfect 3.00 on the flow that had broken for everyone a year earlier. Most participants never noticed the public/internal split had been removed at all.

The finding that stuck

Nobody could find Forms. They looked in Automations, Contacts, Sales and Reporting first. The merge was invisible; the front door was not.

Three stat tiles from the second usability round — Round two, a year after round one. The flow that broke for everyone scored perfectly, the merge went unnoticed, and the only friction left was the front door.

I won’t use AI for minor edits: typing instructions takes longer than just doing it. But I would for an entirely new form.Usability study participant

Create form screen with a prompt field reading Describe what your form is for, and AI will generate it instantly, above suggestion chips for Lead capture, Event registration, HR management, Payment and Client feedback — Testing was blunt: nearly everyone tries AI once, so the first output is the whole product. The cold start is designed, suggestion chips and a template fallback, so the first interaction is a nudge rather than an empty prompt box.

05 · Judgment

Where I changed direction

Bar chart of six features ranked by survey respondents, with the top three emphasised — What 25 users ranked, before any of it was on a roadmap. The three darker bars are the three parity features I shipped.

The full rebuild

Data models were already sound: 12+ months and regression risk for marginal value. I unified the surface, preserved the foundation and staged the delivery.

Merging all form types at once

The backend was still genuinely split and checkout carried payment logic the others did not. I merged the two closest and designed the rest in as future states.

Full AI form creation

Testing said users did not want full automation: they want a starter, not an editor. I shipped generation with manual refinement, plus templates as the fallback.

Selling it with a deck

Slides could not make leadership feel a three-year destination. I built a working prototype instead. The “aha” landed in days, and I got the sign-off.

A Kano study on the three candidate features did not match the plan we had already written. Conditional logic was not on the roadmap at all, even though it was the top complaint in the survey and the top-ranked feature in the study. I took the results to leadership with the evidence behind them and changed the roadmap: conditional logic moved up, and the payments phase came out.

Diverging bar chart of Kano satisfaction and dissatisfaction scores for three features — The Kano study that changed the roadmap. Conditional logic was not on it at all despite being the top complaint; payments was scheduled and users were indifferent. I took this to leadership and reordered the plan.

06 · Outcome

What shipped, and what is parked

4→1

Teams needed to own forms

79%

Of the migration moved across seamlessly

3 of 3

Top-ranked survey features shipped

ShippedAll three of the survey’s top-ranked parity features, live to users.

In progressOne independently deployable form service replacing 32 legacy endpoints, twelve addressed, the remaining gaps mapped.

UnfundedFurther build-out was scoped and did not get funded.

ParkedThe unified builder itself: designed end to end and validated in two studies, then parked in the platform-convergence backlog when a company-wide replan took the roadmap slot. I could not win that one.

Forms were spread across four teams. Mine owned four of the seven, and three other teams owned one each. The consolidated service needs one team, and the tech debt and maintenance cost of seven separate implementations goes with it. Consolidation was only half of it: forms are now integrated across every area of the platform rather than sitting inside one product, so a form can be used wherever the work actually happens. Landing that means working across four teams, and the system now carries AI and MCP layers on top of the unified foundation. The migration is running well so far: 79% moved across seamlessly.

I would rather show this honestly than pretend it all landed. The half that shipped is the half I could justify with a ranked user need; the half that did not is the half I could not fund once the replan hit.

Two things I would do differently

I fixed the builder before the front door

The single most repeated finding in testing was that nobody could find Forms at all. Participants looked in Automations, Contacts, Sales and Reporting first. I treated navigation as a follow-on because parity features were what the survey ranked. I would sequence it the other way now: a builder nobody can find does not get used, however good it is, and the fix was far cheaper than the features I shipped ahead of it.

I made the unified builder one large bet

The builder was designed end to end and validated in two rounds, and it needed a single roadmap slot to land. When the company-wide replan took that slot, all of it parked at once. I should have cut it into pieces that could ship independently: the use-case picker and the live preview each stood on their own, and each would have survived the replan without the whole.