An ambiguous market signal turned into a shipped, revenue-generating feature — researched, designed, prototyped in code, and defended technically, by one designer, in two weeks.
Role
Sole Product Experience Designer — end-to-end
Context
Enterprise B2B SaaS · AI-adjacent tender feature
Duration
~2 weeks (ideation to demo-ready)
Stack
Figma · Figma Make · Cursor · Claude · HTML/CSS/TypeScript code-based prototype
Confidentiality note: client names and deal values are omitted under NDA. Feature and product names are withheld and referenced by working title.
A high-priority feature request landed in the pipeline with strong market signal but a vague brief: a general concept for a document-analysis and questionnaire flow tied to tender decision-making. No user research, no functional spec, no technical scope. The company needed it demo-ready fast — Sales was already positioning it in enterprise conversations.
Brief
Strong signal, vague scope
No research · no spec · no technical scope
Two weeks later
Demo-ready, defensible
Working code prototype · data model · 2 clients closed
The feature sat at the intersection of three complexity axes:
tender office workflows involve conditional logic, multi-step approvals, and heterogeneous document types.
extracting structured decisions and questions from unstructured tender documents.
many conditions, many branches, real risk of overwhelming the end user.
An additional constraint: the deliverable was not a static Figma prototype but a code-based prototype — the functional, production-simulating environment I had previously built for the company. It had to behave like the real product, without a real backend or AI connection.
Own the feature end-to-end in a compressed timeline:
The success criteria weren't visual — they were commercial. The feature had to be sellable, and it had to be technically defensible when the client asked "how does it actually work?"
Ran user research on tender office roles and daily workflows, mapping how questionnaires and document decisions actually move through their process. In parallel, ran the business/functional analysis — what business rules the feature must enforce, what edge cases matter — and the technical research on how document analysis and extraction could realistically work in production.
The instinct with complex domains is to expose the complexity. I did the opposite. Structured the flow around the user's mental model — decision first, questions second, document evidence available on demand — rather than around the underlying data structure. Made the conditions and branches invisible where possible, surfacing them only when the user's next action genuinely depended on them.
Designed and built the feature directly in the code-based prototype using AI-assisted development workflows (Cursor + Claude + HTML/CSS/TypeScript). Because the prototype had no backend and no live AI, I designed a simulated data architecture that reproduced how the real system would behave — realistic tender documents, plausible extracted questions, decision states with the correct transitions.
AI-assisted workflows hit a ceiling on the extraction and data-modeling problem — the AI could generate code but couldn't reason about the domain-specific data relationships the tender process actually requires. I stepped in, designed the data model manually, defined how questions and decisions should be represented, and structured the extraction logic so the prototype produced coherent, defensible output during demos.
Presented the finished feature to the engineering team not as a "here's what to build" handoff, but as a working system with architectural implications. Facilitated discussion on the harder points — data structure, extraction pipeline design, edge cases the prototype revealed — and co-developed solutions in the room instead of leaving them for later.
2 weeks
vague brief to demo-ready
2
new enterprise clients secured
1 designer
end-to-end, no handoff step
The feature moved directly from prototype to sales demos and secured contracts with two new enterprise clients. Client feedback was consistent: they had expected the feature to be difficult to learn given the nature of the underlying work, but found it clear, easy to use, well-structured, and visually strong. The feature met their functional requirements as stated in procurement.
The prototype's data architecture and extraction logic became the reference model for the production implementation discussion. Architectural decisions taken during the internal presentation reduced the space of open questions the engineering team had to resolve later.
Delivered end-to-end in approximately two weeks — from vague brief to a demo-ready feature backed by a defensible technical model. The compressed timeline was possible because the code-based prototype workflow removes the handoff step: the design and the working artifact are the same thing.