In use
A translator between teams
What the engineering team is doing is hard for other teams to follow. I designed an environment that translates each person's code output, so anyone can pick up the context without technical knowledge.
Improving work with AI
An era where what comes out fast is a working prototype, not a static screen. I delegate repeating work to AI and keep improving it at the individual, squad, and company level.
In use
What the engineering team is doing is hard for other teams to follow. I designed an environment that translates each person's code output, so anyone can pick up the context without technical knowledge.
Preparing a pilot
When a field engineer heads out without a word, the property owner calls our support team to ask when someone is coming, and support relays it back to the engineer. Now a departure confirmed in Slack sends the owner a text from the company's main number with the estimated arrival time, and finding nearby parking and logging the job happen inside Slack as well. I built it with AI, from plan to deploy, to take repetitive work off another team.
In use
Daily scrums, backlog items, customer issues and milestones are collected from Slack and extracted automatically so none of them go missing. It removes the manual sorting and keeps the process sustainable.
In use
Every term that gets added has to be matched across seven languages, not one. I built a process where the system, not a person, translates what is missing and keeps terms that already exist consistent.
In use
Outside the engineering team, finding out where a translated line shows up on the actual screen means asking one by one, and the answer comes back as a list of text. I put numbered markers on screenshots where each line sits, and clicking a number shows its values in all seven languages right there. One link lets designers, developers and the PM handling translation look at the same screen.
In use
A spec that actually runs, and a prototype at the same time. Internal staff use it before anything reaches customers, so we can check whether a feature works, and it is designed to be the admin the training team uses in real work.
In use
Scattered records are grouped by property, so they become information the team can actually use for customer support and training.
In use
User OS, screen size and mobile environment become the analytics foundation for product decisions. I built a pipeline that collects what we need through Clarity, GTM and GA4.
In use
To see where users get stuck, someone on the product team has to open the Clarity dashboard every day, and when the recordings are deleted, any trace of where users struggled goes with them. The system compares the metrics it collects each day against a normal day and posts to the team Slack only on days the friction signal rises. From that day's sample of recordings, it sorts out the friction by screen and adds it to a separate log.
In use
PRDs, policy documents and screen specs are kept in one place. Slack threads and Notion pages are cross-checked so every requirement has a source on record. At feature kickoff it is what we open to settle policy and see the prototype concept.
In use
Internal dashboards were built one at a time, so they all looked different and lived at different addresses. I made a shared design that loads color, type and top bar rules from one place, then grouped the tools into a hub you open from a single screen.
In use
While building the English version of the customer help center, I matched the terms to the product's English UI and reshot the demo videos on the English screens. The Korean source keeps changing as the designer edits it, so a one-time translation would go stale fast. I built a flow where AI moves only the Korean edits to the English pages, and a person reviews each one before it goes in.
In use
Every hour, the system searches the public web for posts about the product and sends them to the team's Slack channel. Urgent ones, like outage reports, go out right away, and the rest go out together in the morning. A channel that only gets a daily notice saying there are no new posts ends up muted, and the real alerts get buried with it. So I decided that on days with nothing to send, it sends nothing at all.
In use
Reservation backup files list room types only as long IDs, which makes them hard to read outside the engineering team. Drop a file in and a reservation table with real room names and Korea time shows up right in the browser, ready to export to Excel or Google Sheets.
Personal use
To know when an automated engineering task runs, and what it waits for, you have to open the config files one by one. I built a screen that reads those files. It draws the run conditions, the running order and the result of the last run as a flow chart. Click an item and it explains when and why that task runs, in words you can follow without knowing the code.