I designed, implemented, and continue to maintain a connected education-technology product system: the public service experience, structured intake, Firestore-backed operational workflows, student support, automation, and AI-assisted guidance. My ownership spans product structure, UX, responsive frontend work, data flows, integration, documentation, and ongoing iteration.
The system connects a visible service journey to operational follow-through. A user discovers an offering, chooses the relevant path, submits structured information, and creates a record that the internal team can use for follow-up and support. That end-to-end relationship is what makes the work a full-stack product system rather than a collection of marketing pages.
Current organization context / August 2026
A current public entry point.
This selected capture provides present-day organization context; it does not represent every historical implementation contribution.
One system, not a collection of pages
Students needed understandable paths through education and support services. Universities and client-facing teams needed structured ways to receive inquiries and move them into delivery. Internal teams needed less fragmented information and fewer repetitive handoffs.
Treating each form, page, dashboard, or support interaction as an isolated deliverable would have repeated the fragmentation the product was meant to reduce. I structured the work as a connected journey: explain a service, help a person choose a path, collect the right information, store it in a usable form, and give the operational team a clear next action.
That product model shaped both the interface and the implementation. Navigation and content hierarchy had to make the service model understandable before a user reached a form. Forms had to capture enough structure to support follow-up without becoming unnecessarily demanding. Internal workflows had to preserve the meaning of the submission rather than reducing it to an unorganized message.
Workflow walkthrough
Follow one connected product path.
A deterministic explanation of the confirmed public-to-operational workflow. It does not collect data or reproduce a private interface.
Start with a clear service path.
A public visitor can orient around a service need before entering an inquiry workflow.
- Focus
- Service information
- Structure
- Responsive path
- Outcome
- Clear next step
From service journeys to structured operations
I mapped student, university, and client needs into service pathways and content structure. That work included navigation, responsive pages, contact and inquiry patterns, career and newsletter flows, student-support journeys, dashboard concepts, and technical or client-facing documentation.
The interface work was paired with implementation. I built responsive behavior in React, TypeScript or JavaScript, HTML, and CSS according to the module involved. For confirmed data workflows, form submissions connect to Firebase and Cloud Firestore so information can move from a public interaction into an operational record. Public case-study media uses sanitized or redacted submissions because the underlying data can include private student, applicant, or client information.
The architecture diagram shows the relationship between intake, application-side processing, Firestore-backed data, and internal follow-up. It stays at the workflow boundary so private records, credentials, and security-sensitive implementation details remain protected.
AI support as a product layer
AI work in this system is tied to support and information workflows. I designed chatbot flows, prompt structures, knowledge organization, retrieval-oriented assistance, and AI-supported operational patterns where those approaches matched the task.
A knowledge-assisted support flow is not an autonomous agent, and a prototype module is not presented as a public production feature. Each AI element retains its confirmed maturity, with no invented evaluation scores, usage counts, or autonomous behavior.
AI also does not replace the product structure around it. Useful assistance depends on understandable source information, a clear user question, appropriate system boundaries, and a fallback when the workflow should move to a person. Those concerns influenced the knowledge organization and conversational paths as much as the model interaction itself.
My ownership and the organization boundary
My role covered product structure, UX, responsive implementation, Firestore-connected workflows, automation, AI-support systems, technical documentation, cloud planning or implementation where relevant, maintenance, and ongoing refinement.
The scope is specific to the systems and workflows I designed, implemented, maintained, or directly shaped; it does not attribute every organizational activity to me. The public organization site provides business context, while private product evidence is handled separately.
Private implementation screens and documentation require sanitization before public use. The interactive explanation and diagrams therefore show confirmed relationships with neutral, sanitized records rather than imitating original production evidence.
Decisions that kept the work maintainable
I favored shared patterns for navigation, form behavior, responsive structure, and operational states instead of solving each new service flow from zero. That made it easier to refine the product as offerings and support needs evolved.
I also separated public explanation from operational complexity. Users should see a clear next step, not the internal process required to fulfill it. Internally, the captured information needs enough structure to support routing and follow-up. The balance was to keep the public task focused while preserving useful data for the people operating the service.
Firebase and Firestore are confirmed for connected data workflows. AWS and GCP work belongs to the broader product scope, with planning, prototypes, and deployed modules kept distinct.
Maintenance is part of the product work
The system continued beyond initial delivery. I maintained interfaces and workflows, refined content and service paths, updated documentation, and adapted operational structures as requirements changed. That ongoing work matters because education and support products accumulate exceptions quickly: a new inquiry category, a revised service, a different handoff, or a new information need can expose weak boundaries in the original design.
Maintenance also provided a practical validation loop. Instead of treating implementation as a one-time handoff, I could see where an interaction created ambiguity, where information needed more structure, and where a repeated operational action was a candidate for automation.
Evidence, limitations, and next iteration
Direct implementation, the public organization context, and sanitizable private artifacts support the story at different levels. The asset registry distinguishes original captures, diagrams, and reconstructed interfaces, and continues to control permission, redaction, readiness, and provenance.
No project-specific customer, conversion, traffic, or AI-evaluation metric is approved for public use. The supported outcomes are operational: clearer service pathways, structured intake, centralized data capture, better organized support, and workflows that can be maintained and extended.
A reviewed package of selected public pages, one form-to-operation path, and a sanitized support or dashboard state would make the implementation easier to inspect without weakening the privacy boundary.