The project itself :
Project Overview
IntentOS was a project aimed at modernizing True-dtac's chatbot operations, which had grown into a fragmented system managing hundreds of intents and message flows across multiple platforms (Facebook, Webchat, Line, IVR) without a unified, scalable configuration layer.
Problem:
The existing chatbot admin system required managing hundreds of intents and message flows without a clear unique identifier structure, and call-transfer logic was scattered across disconnected settings — making it error-prone and confusing for non-technical operators to configure correctly.
Goal:
A platform that allows operators to configure chatbot behavior, call-transfer rules, and performance monitoring in one place, with logic presented clearly enough that non-technical users can understand the impact of their settings before saving.
My role:
UX/UI Designer and Business Analyst leading the IntentOS admin platform design.
Responsibilities:
conducting requirement analysis with cross-functional teamsstory
boarding,auditing existing data models and workflows
wireframing and high-fidelity UI design
designing information architecture across configuration and reporting modules
Process of Work
Because the chatbot touched multiple business domains — customer segmentation, product eligibility, and intent-level exceptions — the underlying logic was difficult for non-technical operators to reason about. Early versions of the interface exposed these rules as three disconnected toggle panels, with no indication of how Segment, Product, and Bypass Intent conditions actually combined.
Working alongside the product and engineering teams, I focused on:
Auditing the existing data model — uncovering edge cases such as message_code values repeating across different intents, which required redefining the system's actual unique key (platform + intent_code + message_code) before any UI could be trusted to represent it correctly.
Simplifying rule logic into plain language — replacing implicit AND/OR/exception logic with a human-readable rule summary (e.g. "Calls will be transferred when the customer matches the selected segments and products, except when the topic matches a Bypass Intent"), so operators without a technical background could configure transfer rules with confidence.
Designing for scale — reworking components like the Bypass Intent selector to support 10+ (potentially hundreds of) items through search, multi-select, and virtualization patterns, rather than the short static lists the original design assumed.
Structuring the analytics layer — organizing performance reporting into distinct, purpose-built views (Overview, Intent Summary, Offload Rate, CSAT), each pairing a data table with a matching visualization, so stakeholders at different levels could get the right depth of detail.
Pain Points
Data Ambiguity:
The existing system allowed message codes to repeat across different intents without a clear unique identifier, making it error-prone for operators to configure and audit chatbot flows correctly.
Logic Opacity:
Call-transfer rules were split across disconnected toggle panels (Segment, Product, Bypass Intent) with no indication of how conditions combined — leading to confusion about when calls would actually be routed to an agent.
Scalability Gaps:
UI components such as intent selection lists were designed for a handful of items, but real-world usage required managing hundreds of intents — causing usability breakdowns as data volume grew.
The project schematically :
Starting the Design
Here I built some schemes and storyboards to clarify and understand information and architecture of the app. After I created paper wireframes and than proceeded with building digital wireframes with a low-fidelity prototype in order to conduct usability studies with stakeholders.
Sitemap
mapping the platform's structure. The system originally managed dozens of loosely connected configuration screens across different teams' requests, with overlapping or duplicated flows. The goal was to consolidate everything into five clear functional areas — configuration, call logic, reporting, greetings, and access control — so operators could navigate the console without needing to know which team originally built each page.
Message Configuration
The core screen for managing every intent and message flow the chatbot uses across platforms — Facebook, Webchat, Line, and IVR
Key design decisions
Table-first layout, not form-first. With 796+ entries across the system, operators needed to scan, search, and cross-reference message chains quickly — a card or accordion layout would have made it impossible to see relationships between rows at a glance.
Color-coded state badges (
Nextin green,Endin orange) let operators identify flow termination points instantly without reading every row, which matters when auditing whether a promotional flow actually resolves or dead-ends.Composite identity, not a single key. Message codes repeat across different intents by design (e.g. multiple intents can each have their own
msg-Facebook.1) — the table surfacesPlatform,Intent Code, andMessage Codetogether as a visual group, so operators aren't misled into thinking message codes are globally unique.Inline actions over modals for destructive operations. Edit and delete sit directly in the row rather than behind a dropdown menu, since these are high-frequency actions for an admin managing hundreds of entries daily — reducing clicks mattered more than hiding rarely-used actions.
Search scoped to what operators actually look up. The search bar targets
message_codespecifically rather than a generic full-text search, because that's the identifier operators reference when cross-checking against chatbot logs or QA reports.
Call Management — Call Transfer
Configures the rules that determine when an incoming call gets automatically routed to a human agent, based on the customer's segment (e.g. Platinum Blue, Gold), product type (Postpaid, Prepaid), and a list of intents that should always bypass the transfer and stay handled by the bot.
Key design decisions
A plain-language rule summary at the top, before any controls. Early versions had operators piecing together how Segment, Product, and Bypass Intent interacted on their own — a common source of misconfiguration. Placing a single readable sentence ("If a customer matches your selected segments or products, the call transfers automatically — unless the topic matches a Bypass Intent, in which case it won't transfer regardless of segment") above the panels meant operators understood the outcome of their settings before they even touched a toggle.
Three distinct panels instead of one long form. Segment, Product, and Bypass Intent are conceptually different types of conditions (who the customer is, what they use, and what they're asking about) — keeping them visually separate reinforced that they're independent inputs into one combined rule, rather than one flat checklist.
Contextual metadata on each toggle. Tags like "Priority Tier," "New Users," and "Suspended" next to each segment/product give operators just enough business context to make a confident decision without needing to leave the page to look up what each tier means.
Bypass Intent designed for scale from the start. Since the intent list could realistically grow past 10-15 items (Message Configuration alone manages hundreds), this panel got a dedicated search box, Select All / Clear All shortcuts, and a running "Selected: 4 intents" counter — patterns the Segment and Product panels didn't need, since those lists stay small by nature.
Batch save over per-toggle save. All changes across all three panels commit together via a single "Apply Changes" action, with "Clear Configuration" as an explicit reset — preventing a half-saved state where, say, a segment change went live but a bypass intent update didn't.
Audit trail visible without leaving the page. "Last Update: admin_user · Date: 2023-10-27 14:30" sits persistently in the footer, since call-routing logic is high-stakes enough that operators needed to know who last touched it and when, at a glance.
Report — Performance Summary (Report View)
The primary analytics landing page, giving a cross-cutting view of chatbot usage — Monthly Active Users, breakdown by channel, by product, and a detailed pivot table by sub-channel — all filterable by date range, channel, topic, and period.
Key design decisions
Report / Dashboard as a toggle, not two separate menu items. Both views answer "how is the chatbot performing," just at different resolutions — one tabular and precise, one visual and quick-scanning. Keeping them as a toggle within one page (rather than two nav items) reinforced that they're two lenses on the same dataset, not two different reports.
Grand Total row pinned at the top of every table, so operators get the headline number before scanning individual channels or products — critical when the table itself can run to dozens of rows.
The Sub Channel pivot table is deliberately separate from the summary cards above it. Channel and Product summaries answer "what's the breakdown," while the pivot answers "give me the raw cross-tab for a deeper cut" — collapsing them into one table would have forced casual users to wade through a 10+ column pivot just to see a Grand Total.
Shared filter bar across both Report and Dashboard views, so switching between them doesn't reset the analysis context — an operator narrowing to "Sales Inquiry, October 2023" stays in that context whether they're reading tables or charts.
Report — Performance Summary (Dashboard View)
A visual, KPI-first version of the same underlying data — sales performance, revenue trends, and device-level breakdowns — designed for a faster read than the tabular Report view.
Key design decisions
KPI cards above the fold, before any chart. Revenue V2 and Device+Acc figures (with a visible +12% delta) sit at the very top, since stakeholders checking this dashboard are often looking for a single "are we up or down" answer before anything else.
Line charts for trend, donuts for composition — never both encoded in one chart type. Revenue over time needed a shape (Topping Revenue, Device & Acc Sales), while segment/market splits needed a proportion (Post vs Pre, IR vs Domestic) — mixing these into one chart type would have made one of the two questions harder to answer at a glance.
Horizontal bar-list for device revenue share instead of a large multi-slice donut. With 8+ device models, a donut chart's slices would have become too thin to compare reliably — a ranked horizontal bar list keeps every item legible and directly comparable, at the cost of losing the "circle" visual metaphor.
A visible sync timestamp ("Sync Status: Oct 24, 2023 · 10:00 AM") sets expectations that this is periodically refreshed data, not real-time — important so stakeholders don't mistake a dashboard snapshot for a live feed.
Report — Intent Summary
A ranked breakdown of every intent by call volume and usage share, paired with a grouped bar chart comparing performance across channels (Facebook vs Webchat).
Key design decisions
Status tags derived from usage thresholds ("High Usage," "Active," "Stable," "Low," "Inactive") turn a raw percentage into an immediately actionable signal — an operator scanning the table doesn't need to mentally bucket "35%" as high or low; the system already did that.
Inline progress bars next to the percentage, not just the number alone — giving a visual sense of relative scale across rows without needing to compare raw numbers manually.
Table and chart share the same intents but serve different questions. The table ranks all 24 intents by volume; the chart compares a subset by channel — this separation exists because "which intent is used most" and "does this intent behave differently on Facebook vs Webchat" are genuinely different analytical questions, and cramming both into one visualization would have diluted both.
Pagination on the table (7 of 24 shown) rather than an infinite scroll, since operators typically care most about the top few intents — pagination keeps that priority order visible without forcing a scroll past it.
Report — Performance Summary (Dashboard View)
A visual, KPI-first version of the same underlying data — sales performance, revenue trends, and device-level breakdowns — designed for a faster read than the tabular Report view.
Key design decisions
KPI cards above the fold, before any chart. Revenue V2 and Device+Acc figures (with a visible +12% delta) sit at the very top, since stakeholders checking this dashboard are often looking for a single "are we up or down" answer before anything else.
Line charts for trend, donuts for composition — never both encoded in one chart type. Revenue over time needed a shape (Topping Revenue, Device & Acc Sales), while segment/market splits needed a proportion (Post vs Pre, IR vs Domestic) — mixing these into one chart type would have made one of the two questions harder to answer at a glance.
Horizontal bar-list for device revenue share instead of a large multi-slice donut. With 8+ device models, a donut chart's slices would have become too thin to compare reliably — a ranked horizontal bar list keeps every item legible and directly comparable, at the cost of losing the "circle" visual metaphor.
A visible sync timestamp ("Sync Status: Oct 24, 2023 · 10:00 AM") sets expectations that this is periodically refreshed data, not real-time — important so stakeholders don't mistake a dashboard snapshot for a live feed.
Report — Offload
Tracks how much of the chatbot's traffic is resolved through self-service versus handed off to a human agent, broken down daily (with per-intent handling time) and visualized monthly over a full year.
Key design decisions
Percentage shown next to the raw count on every cell ("10,582 (85%)"), not as a separate column — because offload rate is meaningless without knowing it's a rate of something; keeping the two together prevented operators from misreading a percentage out of context.
Two units in the same table — counts and seconds — clearly separated by row, not column. "Total Incoming/Self-Service" are volume metrics, while "Intent 01–04" rows are handling-time metrics; rather than force them into a uniform column type, each row's data reflects what's actually meaningful for that metric (a handling-time percentage means something different from a volume percentage).
Stacked bar chart (Chat Agent vs Self) instead of a single offload-rate line. A single trend line would show whether offload is improving, but not the absolute scale of traffic behind it — stacking the two categories lets viewers see both the rate and the raw growth in volume simultaneously, which matters since a rising offload rate on shrinking traffic tells a very different story than one on growing traffic.
The project schematically :
Outcome
Since this was an internal admin platform delivered based on client requirements, the outcome centers on operational clarity and scalability rather than public-facing metrics like conversion or engagement. Concrete results from the design work:
Eliminated a class of configuration errors at the source. By identifying that
message_codewas never meant to be a globally unique key, the redesigned data model (platform + intent_code + message_code) removed the ambiguity that made the original system error-prone to configure and audit.Turned an opaque business rule into something operators could self-serve. The Call Transfer logic — previously three disconnected toggle panels — became understandable through a single plain-language rule summary, reducing dependency on developers or BAs to explain "why did this call route the way it did."
Designed ahead of the data, not just for it. Components like Bypass Intent search and the Sub Channel pivot table were built to handle growth (10+ to hundreds of items, 20+ pivot rows) rather than the small sample sets shown in early requirements — avoiding a redesign cycle once real production data landed.