Rethinking Vona's product structure
Vona is an AI storytelling platform that helps people turn memories into written stories. A Story is the content users create. A Production is its published form — audio, video, book, and so on. The two existed as disconnected objects with no shared container, which fragmented the user experience and made the product difficult to scale.
As the sole product designer, I identified this structural flaw, proposed a new model, aligned stakeholders, and shipped the redesigned architecture within one month.
Where things stood
At this stage, Vona had one workspace: Stories. Productions did not exist in the product yet. The CEO had shared a set of wireframes proposing a new Productions workspace as part of the eBook production rollout. That was the starting point.
The challenges this created
The proposed structure worked for the eBook rollout, but it was not built to support anything beyond it. With no shared container between Stories and Productions, users would have to piece together the relationship between their content and its published form on their own.
On the product side, every new feature would expose the same gap. How do you organise multiple Productions across multiple Stories without a shared structure? How does version history work when Productions live in a separate workspace? These are features Vona would naturally want to build. Without fixing the structure first, every one of them becomes a workaround.
Exploration and Testing the Initial Proposal
Before proposing a new structure, I dug into the proposed two-workspace model to understand if it could actually support Vona's future. I mapped out what would happen as the product expanded:
I started by stress-testing the original structure against Vona's likely feature roadmap. Version control became the first problem. If a user had multiple Productions from the same Story, how would they know which Production came from which draft? Without a shared container, there was no clean way to track the lineage between a Story and its Productions. I also explored multi-format production flows. A user might want to produce the same Story as both an audiobook and an eBook. In the proposed model, each format would exist as a separate Production in isolation, with no way to surface that they came from the same source. This meant duplicate content relationships and potential user confusion.
The scaling problem became clearer when I considered batch operations. What if a user wanted to update metadata across all Productions from a specific Story, or download all variations at once? The separate workspaces made these workflows fragmented and unintuitive.
The solution
The fix was to introduce a Project layer. The new model had Project as a container for Stories, with Productions nested within them. This gave users a clear mental model and gave the product a structure it could actually grow into.
Outcome
The new architecture shipped within one month. The Project-as-container model became the structural foundation for Vona's product, giving the team a clean base to build new features on without workarounds. The disconnect between Stories and Productions was resolved through a shared, intuitive structure.
giladrfg@gmail.com