This page collects case studies showing how I take messy systems, workflows, and problems and turn them into something simpler, clearer, and easier to use.
Each one walks through how I understood the problem, organized what was actually going on, and built or documented a system the next person can actually follow.
Short on time? Start with the enrollment system case study. It shows the strongest mix of systems documentation, UI/UX design decision, workflow mapping, and technical explanation.
<aside> 💡
Summary:
A capstone project built around turning the school's manual, in-person enrollment process into a documented, structured online workflow. I mapped how enrollment actually happened step by step, then designed the screens and documentation needed to build it, for the people who'd use it and the people who'd build it next.
Focus:
Systems documentation, UI/UX, BPMN workflow mapping, database planning, and user-centered design.
What this shows:
Proof that a messy, undocumented process can become something people can actually follow, mapped, structured, and written clearly enough for whoever has to use or build it next.
Best viewed for:
Recruiters or teams evaluating process mapping, technical documentation, or user-centered systems thinking applied to a real project, not just claimed on a resume.
</aside>
<aside> ⚡
Summary:
A personal webfolio project built with HTML, CSS, JavaScript, GitHub, Netlify, and a custom domain. This case study documents how the site works, how it was deployed, and why each technical decision was made.
Focus:
Systems planning, technical decision-making, accessible front-end build, deployment, and documentation.
What this shows:
Proof I can take a system from a blank page to something live, planning the structure, making and justifying real tradeoffs, building and shipping it myself, then documenting it clearly enough for someone else to pick up.
Best viewed for:
Recruiters or teams evaluating how someone plans a system, makes technical decisions, and follows through to execution, not just documents something after it's already built.
</aside>
<aside> 🔍
Summary:
A price lookup tool for a small, family-run sari-sari store. Staff, including me, kept getting asked "how much does this cost?" and had to search a handwritten notebook every time. This tool answers that instantly, works offline, and needs no login. Built with plain HTML, CSS, and JavaScript, no framework, no database.
Focus:
Offline-first design, minimal scoping, accessibility, real-world deployment.
What this shows:
I can build exactly what a problem needs, nothing more, and ship something people actually use every day without a server, a login, or a framework in the way.
Best viewed for:
Recruiters or teams evaluating technical scoping, offline-first engineering, or how someone decides what not to build.
</aside>
<aside> 🧭
Summary:
A platform built for a university research team studying whether student teachers lose lesson-planning judgment by relying on AI too early. Working from the client's content and requirements, I designed and built the full platform, no framework, no backend, so it could run reliably on any laptop in front of a thesis panel.
Focus:
Client-based development, UI/UX design, accessibility, offline-reliable architecture, testing, and documentation handover.
What this shows:
Proof I can take someone else's research requirements and turn them into a real, working system, then test, document, and hand it over the way an actual client engagement requires, not just build something and walk away.
Best viewed for:
Recruiters or teams evaluating client-facing development, technical documentation, or how someone finds and fixes real bugs, not just how a finished feature looks.
</aside>
<aside> 💬
Summary:
Two webpages built for the same university language assignment, for two different students. Myanmar was built for another student's group requirement, where I had free rein on the visual direction and information architecture, and I built something closer to a small app than a static page. Indonesia was built for a different student's requirement, from the content and details their page needed. Both are now restructured from a single graded file into clean, documented repos.
Focus:
Front-end build, information architecture, search and navigation UX, working from someone else's requirements.
What this shows:
Proof I can take creative ownership when I'm given the room for it, and just as easily build from someone else's content and direction when that's the job, not just one or the other.
Best viewed for:
Recruiters or teams evaluating front-end build skills, information architecture, or how someone handles building to their own judgment versus someone else's requirements.
</aside>