Robotic Process Automation has a UX problem baked into the name: the robots do the work, so the interface has to explain work the user never sees. My redesign of Woobot centered on making the invisible legible: what is running, what broke, and what a robot actually does when you build one.
The control center
One dashboard shows the KPIs of every robot in operation: which are running, which have errors, the most recent result of each run, the user's recent activity, and overall system health. When something automated fails at 3am, this is where you find out it happened, and where.
Building a robot out of four blocks
The flow chart concept reduces "program an automation" to connecting four kinds of blocks, each with room for commands and customization:
- Trigger block. What wakes the robot up: a single event, like a web form being submitted, or a schedule, like compiling a database every weekend.
- Action block. What it does: send an email, push a notification, create a database entry. Preset actions, connections to the integrated apps, and an advanced mode for going off-road.
- Logic block. An if-else node fed by an action's result, splitting the flow into two paths the user defines.
- Time-based block. Scheduled gathering, sending, or saving. The automated newsletter that reads every lead's address out of the database is this block doing its job.
If a user can wire four blocks together, they can automate a process. That was the whole bet.
Robot health and logs
Every robot gets its own health view: whether it is running, what data is flowing into it, and individual runtime logs for diagnosing exactly what happened on any run. Workflows can also be shared from one account to another, so a working automation never has to be rebuilt from memory.