REVIEW 1
Show where answers come from
Raised
The reviewers asked where the information in an answer comes from.
Changed
Answers end with numbered sources and a Learn more row of linked sites with their icons.
Case study · Sorba.ai · Sorbot
AI guidance,
inside the workflow.
Designing trust for an LLM assistant in industrial IoT: visible reasoning, cited sources, failure states and a reminder to verify.
01Problem
Node setup is technical.
An LLM assistant had to help without asking users to trust it blindly.
02Decision
Trust built into the UI.
Visible reasoning, cited sources, failure states and a reminder to verify.
03Result
30 → 10 min
Estimated time to configure an unfamiliar node, per the team.
ConstraintNo direct access to industrial users. I reviewed with developers from other projects and defined the usability tests below as next steps.
Context
Helping users navigate technical complexity.
IoT Unified brings together a large volume of data and many configurable nodes. The company wanted an assistant for questions about node setup and configuration. The design needed to offer help while leaving room for the task itself.
I worked from requirements set by the project manager and the heads of development. The calls on interaction, trust cues and where help appears were mine.
My contribution
- Reviewed conversational interface patterns and adapted them to IoT Unified.
- Designed the dedicated workspace and embedded assistant panel.
- Designed model selection, starter actions and prompt suggestions.
This case covers the interface design: how people ask questions, choose a model and are prompted to verify responses.
Pattern research
Learning from familiar AI interfaces.
I explored ChatGPT, Gemini, DeepSeek and other AI products as references, then iterated on what could fit IoT Unified. This was a review of interface patterns, separate from research with end users.
- ChatGPT
- Gemini
- DeepSeek
The design questions: how should someone begin a conversation, understand the available controls and choose a model? I adapted those patterns to questions about industrial data and configuration.
What I adapted
A familiar message composer, task-oriented starting points, a visible model selector and a reminder to verify responses.
Design decisions
Two places to ask for help.
I gave broader questions a dedicated workspace and put focused help beside node configuration. That second entry point keeps the form nearby, but it also competes for space.
Dedicated workspace
- Start
- Open Sorbot
- Ask
- Read
- Verify
- Decide what to change
Room for a broader conversation, starter actions and model selection.
Embedded panel
- Start
- Open the panel in a node flow
- Ask
- Read
- Verify
- Change the form beside it
The question sits beside the configuration form.
The panel takes space from the form, so fields can be hidden.
The form stays in view
The Groups configuration form remains visible while the assistant is open.
It costs space
The panel covers part of the form: the Alias field and the Search box are partly hidden.
A panel you can close
The assistant opens inside the flow with a header and a close control, so it does not replace the task.
Quick replies
Suggested replies give people a starting point before they type their own question.
The trade-off: conversation space or task context
Retrospective comparison, not a record of tested alternatives. Whether both entry points are needed remains a validation question.
Decision 02 — Make the model choice visible
The user chooses the model.
The design exposes more than one model. I kept the selector visible in the dedicated workspace and used an explicit list of names, so the choice is available without opening settings.
Visibility does not explain which model fits a task. I would test whether people can make that choice, or need descriptions and a recommended default.
Model options shown in the design. No performance ranking is implied.
Decision 03 — Give users a way to begin
Turn a blank prompt into a starting point.
The home offers starter actions, while this exploration suggests questions about channels, flows, smart rules, alerts and permissions. I used the language of IoT Unified to make the blank composer less abstract.
Each suggestion also sets an expectation about what Sorbot can answer. Those prompts still need to be checked against the assistant’s actual capabilities.
Decision 04 — Set expectations about AI responses
Guidance still needs verification.
I included a reminder to verify Sorbot’s responses. An answer should be checked before it informs a configuration change. Next, I would test whether users can verify an answer before changing configuration.
In-product reminder
SORBOT isn’t perfect—it’s a good idea to verify its responses.
The interface also shows what Sorbot is doing: it lists its steps while it thinks, ends answers with their sources and says so when the connection drops.
Working
A status line and a collapsed Thoughts panel show that Sorbot is working on the question.
Thought process
The Thoughts panel lists the steps (detecting intent, planning, checking the context), then the answer follows.
Sources
The answer ends with numbered sources, linked sites and icon actions: listen, copy, like, dislike, regenerate.
Connection lost
If the connection drops, the interface says so and that it is trying to reconnect.
Iteration & peer review
Reviewing beyond the project team.
The project took approximately two months. I invited developers from other, unrelated projects to review the design as I iterated, which gave me an outside read on the interface before it shipped.
Reviewer feedback → design changes
REVIEW 2
Icons instead of names
Raised
The reviewers asked for icons instead of names to choose where Sorbot searches, and for other controls.
Changed
Each source first showed a short name next to its icon, which worked while there were few. As more were added, I kept only the icons, as ChatGPT and Claude do. The menu opens to each source’s name, a short description, its icon and a toggle.
Design outcome & next steps
Two ways to ask.
Next: validate with users.
The design work brings together a dedicated assistant, chat within a node flow, model selection and starting prompts.
Sorbot is in use at Sorba.ai, and it can be tried through the Sorba trial, which is limited until a paid plan. The trial requires signing up and downloading the demo, so there is no public live link. I no longer have access to the product, so I have no usage data to share.
Before Sorbot, configuring a device or node meant leaving for the documentation or Sorba University tutorials, or asking support. Now people ask in the flow and Sorbot answers from the documentation, with its reasoning and every source visible.
My estimate, from working with the team: about 30 minutes to configure a node you don’t know, and about 10 with Sorbot. It is an estimate, not a measurement; configuration success and support needs are what I would measure next.
2
assistant surfaces designed
≈2
months of work
30→10
minutes to configure an unfamiliar node (my estimate)
Before Sorbot, configuring a node you didn’t know could take around 30 minutes between the documentation and support. Now you ask inside the configuration and it explains how to fill in the device or node, in about 10.
What I would test next
Proposed tasks. I would use representative configuration questions and check the answers independently.
Find help during setup
Ask someone to resolve a configuration question. Watch which entry point they choose and whether the panel blocks fields they need.
Explain the model choice
Ask them to identify the active model and explain what they expect from another option. Look for uncertainty before adding more controls.
Check an answer before editing
In a test environment, observe whether they can spot an incomplete answer, verify it and make a deliberate change. Record where the interface gives too little help.
Reflection
A familiar chat UI is only the starting point.
My next priority is to test how users choose a model and verify an answer during configuration.
I would bring industrial users in earlier and test one configuration task end to end before expanding the interface. That would help me decide which prompts, model controls and response states earn their place.