Zack

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.

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.

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

For the user research phase, I created a 15-question survey distributed to a pool of 150 people to understand how people manage the many different responsibilities that make up everyday family life. The questions explored how tasks enter their lives, from emails, messages, conversations, school-related information, and appointments to financial responsibilities, household management, and family events, and how they currently capture, organize, prioritize, and share them. I also looked at what matters most to them on a daily versus long-term basis, including managing finances, children’s activities, household needs, personal commitments, important dates, and future planning.

The goal was to identify recurring pain points, unmet needs, and patterns in how people handle multiple inputs and responsibilities, giving me a broader and more evidence-based understanding of what they need to stay on top of life, not just what they say they need from a task-management tool.

After gathering and synthesizing the results from the user research pool, I applied the MECE framework - Mutually Exclusive, Collectively Exhaustive - to structure and make sense of the different needs, behaviors, and use cases that emerged.

By grouping related needs into clear, non-overlapping categories, I could identify redundancies, uncover gaps, and prioritize what mattered most to users. This helped turn a large and sometimes fragmented set of research findings into a structured view of the problem space, ultimately leading to a more accurate and evidence-based persona.

The framework gave me a clear way to distinguish what was genuinely different, what was repeated, and what was missing, creating a stronger foundation for defining the product experience.

This structure also helped define the user personas more accurately. Rather than building personas around assumptions or broad demographic characteristics, I could base them on distinct patterns of needs, behaviors, motivations, and priorities identified through the research. The MECE structure made it easier to see which characteristics naturally belonged together and which represented genuinely different user types. This resulted in personas that were grounded in research, clearly differentiated, and representative of the most important user needs, giving the team a reliable foundation for making product and design decisions.

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 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.

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:

Rather than designing one interface at a time, I focused on creating a product capable of evolving while maintaining a familiar and trustworthy experience.

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.

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.

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.

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:

Planning these activities early ensured that product decisions made during development would support long-term adoption rather than short-term visibility.

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.