&mom
Flagship Case Study · Planning & Design
Overview
&mom is a product I am shaping around a straightforward question: how might mothers find local things to do without making discovery feel like another job? I began with a personal conviction that local opportunities can be scattered and difficult to compare. Rather than treat that conviction as a conclusion, I used it as a hypothesis to structure carefully.
This case study is about defining a product before it is ready to make promises: an event-first MVP, a clear audience, a considered journey, and boundaries that keep the first version focused. No ta-da yet. Just the part where the idea gets real enough to build.
Context & Problem
I set the initial audience as mothers in Kern County, California, without making one subgroup the product's priority. The planned experience is for local events and activities for themselves, their children, their families, or connection with other people. That is a product definition, not a demand claim.
The product starts with fragmented discovery: local opportunities may live across different sources, while the details that make an event feel workable can be incomplete or hard to compare. I framed that as a hypothesis. The design question became more specific than “how do I list events?”: how can someone browse what may be available, understand what is known, and decide what to do next without mistaking an incomplete listing for a guarantee?
The MVP stays event-first: one-time and recurring local discovery, practical details and source context, private saving and planning, calendar handoff, and clearly external registration. I left groups, public attendance, comments, reviews, in-app registration, payments, recommendations, and notifications outside the first release. Scope is not a to-do list with better typography; it is the decision that keeps the product legible.
Katey’s Role
My role has been to turn an early personal conviction into product boundaries, then keep them visible as the work becomes more detailed. I have connected the problem hypothesis, audience, MVP, information architecture, flows, screen requirements, and open questions without presenting planning artifacts as proof of a finished product.
I also made privacy and access part of the experience. Browsing should not require an account. Account access belongs at the point someone chooses a private action, such as saving or planning. The initial product does not ask people to disclose a motherhood stage, and it does not collect or infer that information. Those limits shape the product as much as a screen or feature does.
Process & Key Decisions
From Ambiguity to Structure
The central design move was to separate discovering an option from deciding whether it is useful. I explored several ways for Discover to open, then kept the comparison focused on a real tension: should the product begin with a broad inventory or with a person's calendar?
| Explore | What it foregrounds | Tradeoff |
|---|---|---|
| Browse-first feed | A useful cross-county inventory appears immediately, with search and filters available when needed. | It gives date planning less visual priority at the opening moment. |
| Date-first planner | A specific day becomes the organizing frame from the start. | It makes browsing across a wider time range less immediate. |
Both concepts preserve county-wide browsing, optional search and filters, event details, and the same core destinations. The comparison recommended the browse-first feed: start with what may be available, then let a person narrow the field. Search and filters stay close, but secondary to the inventory itself.
The flow begins with public browsing. Sign-in appears only for an account-required action. Calendar and registration remain honest handoffs: adding an item does not create ongoing synchronization, and returning from registration does not mean it succeeded. A save keeps an opportunity in view; a plan refers to a specific occurrence and does not claim attendance.
Solution or Current State
&mom remains Planning & Design. The work now includes an implementation foundation, but that is not the same thing as a working product. There is no public release, public-user evidence, or outcome evidence to point to, so I am keeping the stage label precise.
What exists today is a defined product direction with active foundation work behind it: enough structure to make the next implementation decisions deliberate, not enough evidence to call the experience live.
Evidence & Outcomes
The strongest evidence available today is the planning trail: the event-first MVP, audience and scope choices, information architecture, flow decisions, and screen directions. It shows the product becoming more specific. It does not show that people found otherwise-missed events, changed their habits, registered, attended, or benefited from &mom.
Direct intended-user research is outside the initial plan, and the fragmented-discovery problem remains a hypothesis. The planning evidence shows how I am framing the work; it does not establish that the framing has been validated with users.
Supporting detail
The design work also distinguishes between information that helps a person browse and information that helps them evaluate one event. In the detail view, practical facts sit alongside available fit, source, freshness, status, and trust context, with private planning actions kept predictable rather than interrupting the decision. That is a proposed product experience, not a claim about a live interface.
Reflection & Next Steps
This project has reinforced a pattern I trust: a product becomes more credible when its boundaries are explicit. I do not need to claim that &mom has solved fragmented discovery to show the work of giving that problem a structure. The planning matters because it makes the intended experience, its limits, and its unanswered questions easier to see.
The next meaningful evidence is verified user-facing implementation. Until then, this case study stays grounded in what actually exists: a focused product direction still becoming software.