Jo Ionescu
UX/UI Designer
Conversation UX/AI Designer
A newer version of this portfolio is now live. This website is kept online for reference and will no longer receive updates.
Explore the new portfolio → https://joionescu-designer-portfolio.lovable.app/
Zack
Building an AI-Powered Family Organizer from Concept to Launch
TL;DR
Over 18 months, I helped take Zack from a 120-page brainstorming deck to a launched AI-powered family organizer on iOS and Android, owning product design, product management, project leadership, conversation design, and growth strategy as the team shrank to just the founder, one developer, and me.
Results:
-
Shipped a full product from zero: no existing users, no legacy codebase, no established workflows, to a live app across two stores and a marketing website
-
Built and ran the growth measurement framework myself: mapped every funnel stage to its data source, set benchmarks, and used it to correctly diagnose that the store listings and website, not ad targeting, were the actual conversion bottleneck
-
Beyond tracking: I also ran a full ASO audit on both store listings, keywords, categories, descriptions, and screenshots, so the KPI framework had something optimized to actually measure.
-
Delivered paid acquisition well ahead of cost benchmarks: Meta CPC of €0.88 against a €0.70–1.20 target, and CPM near €7.10 against a €6–14 target, LinkedIn's paid CPC of €2.52 sat inside its own €1.50–4.00 healthy range, reaching close to 290,000 unique people on a lean early-stage budget.
-
Drove average website session time of 4:18, nearly 3x the 45–90 second benchmark for genuine engagement
-
Took the app from zero to 100+ live installs on Google Play
Chapter 1: Overview
Executive summary
Over an 18‑month period I helped transform Zack from an early product idea (a 120 ppt page of brainstorming brief) into a publicly launched AI-powered family organizer available on the Apple App Store and Google Play.
While my official contribution began with product design, my responsibilities quickly expanded across product management, project leadership, conversation design, growth planning, and stakeholder communication.
Working in a lean startup environment meant there was no separation between strategy and execution. I was responsible for connecting business goals with engineering, turning ideas into actionable work, and ensuring that the product continued moving forward every day. During the final eight months, the active team consisted of the stakeholder, one backend developer, and myself, requiring me to lead much of the product coordination alongside design.
This case study tells the story of building Zack from the ground up, not only through interface design, but through leadership, product thinking, and cross-functional collaboration.
Project snapshot
Stakeholder: ZIEL.swiss
Remote role: Lead product designer, product manager, project lead, conversation designer, UX Researcher, growth strategy contributor
Timeline: 18 months
Team:
• Stakeholder / Founder
• Frontend Developer (first phase)
• Backend Developer•
Me (design, product, project leadership)
Platforms:
• iOS
• Android
• Website
The challenge
Creating Zack was not a redesign of an existing product; it was the creation of an entirely new one. There were no users, no historical analytics, and no established workflows to guide decisions. Every feature had to be researched, prioritized, designed, validated, discussed with engineering, and refined through continuous iteration.
The challenge extended far beyond designing screens. Someone needed to maintain product direction, organize the team's work, facilitate decisions, and ensure that development stayed aligned with the founder's vision while remaining realistic from an engineering perspective. I stepped into that role.
My role
Although I joined as the product designer, I quickly became the operational bridge connecting design, development, and business. I facilitated design sprints, led daily working sessions, maintained the product roadmap, managed the Trello backlog, translated stakeholder requirements into actionable development tasks, reviewed implementation with developers, and continuously reprioritized work as the product evolved.
Every day involved reviewing progress with developers, updating timelines, refining task cards, clarifying requirements, and resolving blockers before they slowed delivery. Rather than working through isolated design handoffs, I remained embedded throughout the entire development lifecycle. This close collaboration created transparency, shortened feedback loops, and enabled the team to make informed decisions quickly.
As the project progressed and the team became smaller, my responsibilities expanded even further. Alongside designing the product experience, I became responsible for maintaining momentum, aligning priorities, and ensuring that every sprint moved the product closer to launch
Chapter 2: Strategy and product vision
From vision to product
One of the biggest lessons I learned while building Zack was that great products are not created by design alone. They emerge through hundreds of conversations, thousands of decisions, continuous prioritization, and close collaboration between business and engineering.
Although my primary expertise was Product Design, it quickly became clear that creating a successful product would require much more than designing screens.
Every design decision influenced development effort, every business goal affected the roadmap, and every technical limitation required thoughtful compromise.
Rather than working in isolated phases, we built Zack through continuous collaboration, where design, engineering, and product strategy evolved together.
When I joined the project, Zack was still taking shape. Like many early-stage startups, the vision was ambitious, but many of the details had yet to be defined.
Instead of treating design as a process of creating interfaces, I approached the project as an opportunity to build the product from its foundations.
Every feature began with the same questions:
-
What problem are we solving?
-
Why does this feature matter?
-
Is it valuable enough to justify the development effort?
-
Can users understand it immediately?
-
Does it support Zack's long-term vision?
Those questions became the framework behind every product decision.
As the product matured, Zack evolved from a productivity-focused assistant into an AI-powered family organizer. This evolution wasn't driven by assumptions, it was the result of continuous discussion, exploration, and refinement.
Together with the stakeholder, we challenged ideas, re-evaluated priorities, and reshaped the product to better address the everyday challenges families face in organizing their lives.
Building a shared product vision
One of my key responsibilities on Zack was ensuring that ZIEL's stakeholders, the development team, and the product itself were all moving toward the same vision: an app that doesn't just list what a family needs to do, but actually gets it done.
In a startup environment like ZIEL's, priorities shifted constantly, a new competitor angle would surface, a technical constraint on AI task-parsing would emerge, or the brand direction itself would evolve (as it did when we moved from "productivity" language to relief-first language like "Done. Closed. Off your plate.").
Without a clear anchor, it would have been easy for the team to drift back toward building "just another task manager."
I became responsible for translating high-level business ambitions, like owning the "family organizer" category rather than competing feature-by-feature with Todoist or Cozi, into product initiatives that both developers and stakeholders could act on. This required balancing three perspectives simultaneously: the needs of the target persona (a time-compressed working parent carrying invisible mental load), ZIEL's business objective of building a defensible market position, and the technical realities of what the AI could credibly deliver (turning a school email into a task with a deadline, not vague "smart AI" promises).
Rather than letting these perspectives compete, I worked to align them into a shared vision, captured in the "Capture to Complete" flow, that guided every sprint and every product decision.
Due to sensitive data, the positioning document below was cropped in order to be able to be shown publicly:
Product thinking before feature thinking. Product discovery.
One principle shaped nearly every decision I made throughout the Zack project: features don't create value, solutions do.
Whenever a new idea was proposed, another integration, another view, another reminder type, my first instinct wasn't to ask how it should look. It was to ask whether it genuinely closed the loop for a parent already juggling WhatsApp messages, school PDFs, and a calendar that don't talk to each other.
That question is what shaped the competitive moat we defined: Zack's value wasn't in capturing tasks (every to-do app does that), it was in supporting, coordinating, and completing them, the parts competitors like Google Tasks or ChatGPT stop short of.
This approach encouraged thoughtful prioritization over feature accumulation. Rather than expanding Zack with every interesting idea, I focused on identifying the features that delivered the greatest relief with the least added complexity, consistent with the six core pillars and the decision to replace a generic "download now" CTA with something that describes an outcome, like "Add one task you've been carrying too long."
This mindset helped prevent Zack from becoming another cluttered productivity app, and kept development effort focused on functionality that matched both the family organizer's real expectations and ZIEL's long-term positioning goals.
Chapter 3: Design process
From sketch to structure
Before any of this reached Trello or a screen, it started on paper.
I sketched full onboarding flows, splash screen through sign-up, login, and personal achievements, and iterated on dashboard layouts by hand, testing different arrangements of calendars, task lists, and quick-add actions until the structure felt intuitive rather than crowded.
For messier, more open-ended problems, like figuring out what categories of "family life" Zack actually needed to cover, I used sticky-note affinity mapping: writing out raw ideas (subscriptions and renewals, childcare and babysitting, side gigs and freelance, language learning) and physically grouping them until clear categories emerged. I mapped the settings and preferences architecture the same way, working through account structure, integrations, notification logic, and the achievements/badges system on paper first. This low-fidelity sketching phase let me move fast, throw away what didn't work, and arrive at digital wireframes with the core logic already validated.
Designing for simplicity in a complex product
Designing Zack meant solving a difficult challenge: creating a product capable of managing the complexity of everyday family life while making every interaction feel simple and intuitive.
The product brought together task management, calendars, reminders, AI assistance, achievements, notifications, and collaboration within a single ecosystem. Each new feature had the potential to increase cognitive load, so one of my primary goals throughout the project was to protect users from unnecessary complexity.
Instead of designing individual screens in isolation, I focused on designing an experience that felt cohesive from beginning to end. Every interaction was evaluated through a single question:
"Does this help users accomplish their goal with less effort?"
This principle influenced every design decision, from navigation and information hierarchy to interaction patterns and microcopy.
Rather than presenting users with every available option, I intentionally revealed information progressively, ensuring that the interface remained approachable for new users while still providing the flexibility required by more experienced ones. Every screen had a clear purpose, every interaction needed to justify its existence, and every element had to contribute to a smoother user experience.
Designing with systems, not screens
One of the biggest shifts during the project was moving away from thinking in terms of individual pages and toward designing a scalable product system.
As Zack expanded, consistency became increasingly important. New features were introduced regularly, AI capabilities evolved, and the product continued to grow beyond its original concept. Without a structured design system, maintaining visual consistency and development efficiency would have become increasingly difficult.
To address this, I developed reusable design patterns, standardized components, and consistent interaction behaviors that could be applied throughout the application.
This approach created several benefits:
-
Developers could implement features more efficiently using consistent UI patterns.
-
Users experienced predictable interactions throughout the application.
-
Future features could be designed and integrated without introducing unnecessary visual inconsistency.
-
Rather than designing one interface at a time, I focused on creating a product capable of evolving while maintaining a familiar and trustworthy experience.
Chapter 4: Conversational AI design
Designing Conversations for AI
Making AI feel helpful, not complicated
One of the most distinctive aspects of Zack was designing conversational experiences powered by artificial intelligence.
Unlike traditional interfaces, conversational products require users to communicate through language rather than navigation alone. This introduces a unique challenge: users may express the same intention in many different ways, while expecting consistent, reliable, and helpful responses.
My role extended beyond interface design into Conversation Design, where I defined how Zack should communicate with users in a way that felt intuitive, supportive, and trustworthy.
The objective was never to make Zack sound human.
The objective was to make Zack genuinely useful.
Designing conversations with purpose
Every conversation needed to accomplish something meaningful.
Rather than treating AI as a novelty feature, I designed conversational flows that helped users complete tasks, organize information, receive guidance, and reduce the friction often associated with traditional productivity tools.
This involved designing:
-
onboarding conversations that introduced the product naturally,
-
prompts that encouraged meaningful user input,
-
conversational pathways for task creation and organization,
-
clarification and confirmation flows,
-
fallback responses when user intent was unclear,
-
supportive messaging that maintained user confidence during unexpected situations.
Every interaction was designed to keep conversations focused, understandable, and efficient.
Building trust through conversation
Trust became one of the most important design principles.
Users needed confidence that Zack understood their requests, handled information responsibly, and communicated clearly whenever uncertainty existed.
Instead of allowing AI to make assumptions, I designed confirmation points for sensitive actions, informative feedback after important interactions, and graceful recovery paths whenever clarification was required.
By designing transparency into the conversational experience, we reduced ambiguity and helped users remain in control of their interactions.
Ultimately, successful conversational design wasn't about making AI appear intelligent, it was about making users feel understood.
Chapter 5: Leadership and product management
Owning the product roadmap
As the project progressed, I assumed responsibility for maintaining the product roadmap and coordinating the day-to-day planning of development activities.
Trello became far more than a task management tool, it became the operational backbone of the project, holding not just the roadmap but the team's communication and sprint structure as well.
Every user story, feature request, enhancement, technical dependency, bug, and design iteration was translated into clearly structured work items. I organized the board around weekly sprints, each with its own dedicated list (Sprint June 30–July 7, Sprint July 7–14, and so on), alongside dedicated boards for ongoing UX/UI work and feedback.
I continuously refined task descriptions, organized priorities, updated timelines, clarified implementation details, and ensured that developers always had the context they needed before beginning work, with every comment, attachment, and checklist item living directly on its card so nothing got lost between conversations.
Because startup priorities evolved constantly, the roadmap remained a living document.
New insights from discussions, product decisions, or technical discoveries often required immediate adjustments. Rather than viewing these changes as disruptions, I treated them as opportunities to improve the product while maintaining transparency across the team.
Keeping the roadmap accurate and actionable, and the sprints clearly organized, allowed us to move quickly without sacrificing alignment or quality.
One of the most rewarding aspects of this project was helping create a collaborative environment where ideas could move efficiently from concept to implementation.
Every day involved close communication with the development team.
We reviewed ongoing work, discussed implementation challenges, clarified requirements, and adjusted priorities whenever new information emerged. These conversations were never limited to reporting progress. Instead, they served as active working sessions where design decisions were refined, technical questions were resolved, and the next steps became clear.
As the project entered its final stages and the team became smaller, this rhythm of collaboration became even more important. With only the stakeholder, the backend developer, and myself driving the product forward, every conversation directly influenced the direction and pace of development.
By maintaining open communication and a shared understanding of priorities, we were able to make faster decisions, reduce misunderstandings, and keep development moving despite limited resources.
Leading product development
Beyond design: Becoming the product lead
As development progressed, my responsibilities expanded beyond product design.
In a small startup environment, roles are rarely confined to job titles. The success of the product depended not only on creating a great user experience, but also on ensuring that the team remained aligned, informed, and moving in the same direction.
I gradually became the operational bridge between the stakeholder and the development team, translating business objectives into actionable work while ensuring technical realities informed product decisions.
This leadership role became one of the defining aspects of my contribution to Zack.
To maintain momentum throughout the project, I facilitated design sprints and structured collaborative sessions that brought together product goals, design thinking, and engineering perspectives.
These sessions were not simply opportunities to review work; they were decision-making workshops where we challenged assumptions, discussed implementation approaches, identified risks, and agreed on priorities for upcoming development cycles.
In addition to sprint planning, I led daily working sessions with the development team.
Together, we reviewed progress, discussed blockers, clarified requirements, refined solutions, and ensured that everyone understood both the immediate objectives and the broader product vision.
Maintaining this rhythm of communication significantly reduced ambiguity and allowed the team to respond quickly as new information emerged.
Leading through ownership
During the final eight months of development, the active team consisted of only the stakeholder, one backend developer, and myself.
With a smaller team, maintaining momentum became increasingly important.
I took ownership of coordinating daily priorities, facilitating collaboration, tracking progress, reviewing completed work, identifying potential risks, and ensuring that every sprint moved the product closer to launch.
Working in this environment strengthened my ability to lead without formal authority. Rather than managing people, I focused on creating clarity, fostering collaboration, and helping the team make better decisions together.
This experience reinforced an important belief that continues to shape my approach today:
Leadership is not defined by title, it is demonstrated through ownership, communication, and the ability to help a team move confidently toward a shared goal.
Building for launch. Planning growth and measuring success.
One of the most rewarding aspects of the project was contributing to Zack's long-term growth strategy.
Instead of thinking about launch day as the finish line, I approached it as the beginning of the product's relationship with its users.
Working alongside the stakeholder, I developed a structured growth roadmap that outlined activities from pre-launch through the first five months after release.
This included defining:
• launch milestones,
• communication strategy,
• distribution channels,
• key performance indicators (KPIs),
• analytics priorities,
• user engagement opportunities,
• notification strategy,
• and projected product growth.
Planning these activities early ensured that product decisions made during development would support long-term adoption rather than short-term visibility.
KPIs
Before this campaign launched, there was no shared definition of what success would actually look like, or which numbers mattered enough to check every week.
I built a KPI framework from scratch, mapping each stage of the funnel to its data source, the specific metric that mattered at that stage, current industry benchmarks, and what a healthy or unhealthy reading would actually mean. I shared this with the founder and the developer before the campaign started, not after, so that when the numbers came in, we already had shared language for whether something was working or not, and where in the funnel to look first if it wasn't.
That framework is what let us diagnose, with confidence, that the store listings and website were the actual bottleneck, not the ad targeting, well before assumptions could take over the conversation. The framework includes in-app analytics and KPIs and organic content and paid ads (Meta and LinkedIn) KPI benchmark.
Beyond tracking: Alongside building the KPI framework, I ran a full App Store Optimization audit on both listings, refining the app name and keyword string for search relevance, selecting the right primary and secondary categories, and rewriting the store descriptions and screenshot sequence to lead with outcomes rather than features. ASO and KPI tracking worked together: the audit shaped what the listing said, and the KPI framework measured whether it was actually converting.
Launching a product is only the beginning.
The real work starts when users begin interacting with it.
Chapter 6: Results and impact
Results and impact
From concept to reality
Even with a lean early-stage budget, the campaign reached roughly 290,000 unique people across 392,000 impressions in under two weeks, at a cost efficiency well ahead of target: Meta's cost-per-click landed at €0.88 against a €0.70–1.20 benchmark, and cost-per-thousand-impressions came in near €7.10 against a €6–14 benchmark. LinkedIn's paid CPC of €2.52 sat comfortably inside its own €1.50–4.00 healthy range. On the website, visitors who landed spent an average of 4 minutes 18 seconds on the page, nearly three times the 45–90 second benchmark for genuine reading and interest, and 96% of sessions came from new, previously unreached visitors. Organic content on Meta also drove real engagement without any ad spend behind it, and the app has since crossed 100+ installs on Google Play.
My Contribution
Looking back, my contribution extended well beyond traditional product design responsibilities.
Throughout the project I contributed across multiple disciplines, including:
Product Design
-
UX research
-
Information architecture
-
User flows
-
Wireframing
-
UI design
-
Design systems
-
Prototyping
-
Accessibility
Product Leadership
-
Product vision
-
Feature prioritization
-
Sprint facilitation
-
Roadmap management
-
Trello administration
-
Daily team coordination
-
Cross-functional collaboration
Conversation Design
-
AI conversation flows
-
Prompt design
-
Conversational UX
-
AI interaction strategy
-
User guidance
Product Strategy
-
Growth planning
-
KPI definition
-
Analytics planning
-
Notification strategy
-
Feature prioritization
Launch Preparation
-
App store assets
-
Google Play assets
-
Product documentation
-
Terms and conditions proposition
-
Privacy policy proposition
-
Launch planning
Working across these disciplines allowed me to contribute not only to how Zack looked, but to how it was planned, built, delivered, and prepared for market.
Final reflection and professional growth
Working on Zack fundamentally changed how I approach Product Design.
It strengthened my ability to navigate uncertainty, lead cross-functional collaboration, and make product decisions in environments where priorities continuously evolve.
Perhaps most importantly, it taught me that influence does not depend on formal authority.
Over eighteen months, I had the opportunity to contribute far beyond the boundaries of a traditional Product Designer role. I helped transform ideas into product strategy, strategy into actionable plans, and plans into a publicly launched application.
Working in a lean startup environment taught me to embrace ambiguity, make thoughtful decisions with limited information, communicate across disciplines, and maintain momentum even when priorities changed.
Above all, Zack reinforced a belief that continues to guide my work:
Exceptional products are not created by a single discipline. They emerge through shared ownership, thoughtful collaboration, continuous learning, and a relentless focus on solving real problems for the people who use them.
3 final products:
🌐 View live site: