PORTFOLIOSELECTED WORKS / UX · PRODUCT · AI

Turn decisions in the field into
working systems.

2 apps / thought to working product

Turn ideas into
working products.

I led both featured projects end to end, from planning and concept development to visual and information design, implementation, and validation—turning ideas into systems people can use at work.

Portfolio type 02 / applications

Turn Decisions into Working Systems

Two applications and operational systems built to put decisions about analysis, comparison, and project progress into practice and test them in real use.

1. AmazonKeyword Win/Loss Dashboard

Case 01 / Decision-support application

Evaluate search-term wins and losses
with repeatability and profitability in mind.

01 / Decision overview

See wins and losses with their supporting evidence on one screen.

Rather than ranking targets by purchases in the latest period alone, the dashboard combines repeat counts, score, click thresholds, and ROAS in one decision view.

Filter by brand, ad type, evaluation period, appeal theme, or branded keyword.
Review 60 wins, 45 losses, and 15 pending decisions from the same population.
The public demo contains only fictional brands, products, and figures.

02 / Aggregation foundation

Standardize the time period and comparison dimensions before interpreting the numbers.

Before comparing brands or ad types, recalculate sales, spend, efficiency, and sample sizes for the selected period using consistent rules.

Put ad-attributed sales, ad spend, ROAS, and purchases in the primary view.
Review clicks, CVR, CPA, CTR, and CPC using the same period definition.
Recalculate rates from totals instead of taking simple averages.

03 / Appeal and keyword analysis

Group search terms by appeal theme while retaining a path back to individual keywords.

Compare semantically related search terms by appeal theme, then drill down to an individual keyword, product target, or campaign proxy when needed.

Separate four levels: appeal themes, natural-language keywords, SP/SB product targets, and SD proxies.
Compare the latest evaluation with all-time wins, losses, and pending decisions in one row.
Display evaluation groups separately so winning and losing appeal themes are not mixed.

04 / Evaluation criteria

Do not mistake one lucky week for a winning pattern.

Instead of deciding from the latest period alone, combine click volume with repeat performance over time and separate initial from repeat evaluations.

Set minimum clicks, benchmark CVR, and winning/losing ROAS thresholds by brand and ad type.
Keep cases with insufficient data pending instead of forcing a win or loss.
Flag targets with high ROAS but few purchases for further validation.

05 / Long-term trends

Separate efficiency from scale to assess whether a change is sustained.

Start with long-term trends by brand, then review ten key metrics and the ROAS-versus-click distribution.

Keep brand, ad type, and start and end dates synchronized across views.
Compare ROAS, CVR, CTR, CPA, and CPC along the same timeline.
Recalculate from actual sales, spend, clicks, and purchases instead of relying on averages alone.

06 / Change detection

Review alerts for all ten metrics in one place.

Each card shows the latest value, week-over-week change, and whether it is within range; color and sparklines highlight changes that need review.

Review sales, spend, outcomes, traffic, and efficiency in separate charts.
Compare drops in ROAS or CVR and rises in CPA against their thresholds.
Pair color with values, signs, and labels so meaning does not depend on color alone.

07 / Next-test planning

Prioritize what to test next based on expected learning, not predicted wins.

Score candidates for scaling delivery, adjusting bids, or continued observation based on changed and sustained evaluations.

See this week’s changes beside the proposed actions and trace the supporting evidence.
Show priority, action, target, and repeat evaluation in the same row.
Exclude targets without a product mapping or those that require manual review from recommendations.

08 / Implementation and operations

Reproduce the same evaluations by replacing the Excel file.

Raw data is cleaned and aggregated with Python, combined with semantic labels in Excel, and loaded in the browser. Switching views does not trigger another analysis.

Python makes column validation, type conversion, aggregation, evaluation, and joins reproducible.
GPT supplies semantic labels such as appeal themes; numeric evaluations remain in explainable rules.
Excel is processed in the browser and is not sent to an external server.

Open the demo Design and implementation notes

01 / 08

2. Multi-Agent AI Operations Control Room

Case 02 / Local operations system

As AI does more work, people focus on exceptions.

01 / The problem

As AI speeds up, progress tracking becomes the first bottleneck.

Automating tasks does not remove the bottleneck if people still have to copy progress and blocker details by hand.

The status of multiple projects gets buried in chat history.
Blockers, attempted fixes, next steps, and human decisions are recorded in different places.
Bring execution, evidence, learnings, and next tasks into one operations view.

02 / At a glance

Manage multiple projects from one operations view.

The board shows not only active, pending, blocked, and completed projects, but also unfinished work, approvals, and next steps.

See project counts, pending updates, approvals, and remaining items at the top.
Read each status column, from not started through completed.
Summarize status for decision-making instead of exposing raw logs.

03 / Work in progress

Track the next task as well as the current status.

A label such as “In progress” is not enough to resume work. Cards retain the current stage, unfinished items, and next task.

AI agents report starts, completions, blockers, evidence, and next tasks.
Even after an interruption, the next step is clear.
Replace manual progress updates with event records.

04 / Exception handling

Surface the exceptions people need to review instead of monitoring every task.

Show blockers and completion evidence on the same board so people can focus on cards that need a decision.

Pause external messages, publishing, purchases, and contracts at an approval gate.
Do not execute approvals automatically; assemble the evidence and wait for a person.
Keep blockers visible instead of burying them in normal progress.

05 / Project list

Group projects in units that can be resumed.

Connect each project’s purpose, status, and next step from the list to its detail view.

Review counts and project rows for active, blocked, and completed work.
Search to open an individual project record.
Record where to resume, not just who last owned the task.

06 / Project record

Keep the purpose, next step, completion status, and blocker in one place.

Designed as personal project memory that makes it possible to resume without rereading the conversation.

Bring purpose, constraints, current status, outcomes, and unfinished work together.
Trace evidence, approval history, decision criteria, and lessons learned.
Separate the daily operations view from the project records used for later review.

07 / Approvals and learning

Route risky actions to approval and turn failures into better rules.

The operations loop carries a blocker beyond its incident record and back into the criteria used to prevent recurrence.

Handle only brief, sanitized events.
Separate high-risk actions into a pending-approval queue.
Connect failures and improvements to rules for future projects.

08 / Implementation and validation

Use the system in real project operations.

In personal use, the system combines a local static interface, JSON/JSONL as the source of truth, and Python generation and validation.

Check page generation, data validation, UI smoke checks, security, and completion criteria.
If the receiver is unavailable, events are saved to a local inbox atomically.
Productivity gains, multi-user operations, and suitability as an enterprise SaaS have not been validated.