HOME/PROCESSX
ProcessX: A No-code Workflow Builder for Customer Care Automation
- Role
- Solo UI/UX Designer
- team
- 1 UI/UX Designer (me)1 Business AnalystDevelopment team (FE, BE, QA)
- timeline
- Jul 2026 - Dec 2026 (6 months)Status: In progress
- constraints
- Built on IPCC2.0
Context
IPCC2.0 is the IP contact-center platform of Viettel Customer Service, used by care agents across hotlines and online channels. It connects to the business support system that holds billing, subscriptions and customer data.
Current care processes rely on agents remembering steps and switching between the two systems.
ProcessX is a new IPCC2.0 module for designing and running these processes as automated flows.
Problem
Admins think in business steps, not in logic
I joined when the BA had taken in the requirements and was drafting wireframes to align with the client. My first task was to audit UX and interaction with the BA, focusing on the process builder.
BA wireframe
Process builder
Four main issues stood out in the wireframes:
01
The node library mixed real steps with flow controls (branch, merge, go to node), which confused users.
02
Too many panels squeezed the canvas.
03
Each node showed its type, name and details, putting too much text on a single flow.
04
Creating conditions was hard to use, with technical field names.
Research
I studied similar tools to find words and interactions that match how non-specialists think about their work.
Products I studied:
Attio
Automation in plain words
Triggers and actions read like everyday sentences.
Flowable
Powerful, but speaks BPMN
BPMN terms require specialist knowledge
n8n
A node canvas that stays readable
One icon, one label per node, and a “+” for the next step.
Zapier
“When this happens, do this”
Linear steps that mirror how people describe their work.
Solution / Product Decisions
4 Decisions That Turned the initial Wireframes Into an Easier Builder
01
Only real steps in the library
BA wireframe
Steps mixed with flow controls
Flow controls (Go to node, Branch, Merge) sat among the steps, so users were confused about how to use them.
Final design
Steps grouped by what they do
Only steps are listed. Branch types live inside Condition; merge points show right on the canvas.
02
Giving the canvas back its space
BA wireframe
Four columns compete with the flow
Four columns left the canvas less than half the screen.
Final design
Panels open & collapsed
Since steps can be added right on the canvas, the Step library can be opened or closed as needed, keeping the canvas spacious even on small viewports.
03
One label per node
BA wireframe
Each node shows its type, name and details
Type, name and details on every node turned long flows into a wall of text. Node details add the least value when viewing the whole canvas, so they can be simplified.
Final design
Simplified nodes, key info only
Type shown once with its icon, plus a short description.
04
A condition flow non-tech users can follow
BA wireframe
Technical fields
“Object → attribute”, “Operator” and AND/OR were written in domain jargon, not the user’s language.
Final design
Expressed in plain language
Field, comparison and value, all in business terms.
BA wireframe
Building a multi-branch flow was confusing
A multi-branch flow needed separate Branch, Condition and Merge nodes, so users mixed them up or didn’t know which one to use first.
Final design
Pick how branches run
Everything lives in the “Condition” node: users drag it onto the canvas and configure it.
Reflection
For technical, hard-to-use products, UX matters more than ever.
Research clarifies when users work with the product and what their mental model is, so business language can become a friendlier interface.
More projects
