Case study  ·  Sorba.ai  ·  IoT Unified Cloud

From forms to a node canvas.

Replaced a five-sub-step camera wizard with a four-step guided setup and a node canvas.

Role
Product Designer
Timeline
Mar – Jul 2025 · 4 months
IoT Unified Cloud · Vision
The Vision Stream Processors step: a tools palette beside a canvas where a Video Input node connects to a Raw Streamer, an Interests Zone and event nodes, with an expand control at the top right of the canvas
Vision’s Stream Processors step. The canvas makes connections visible; the wider setup stays guided.

01Problem

A pipeline hidden in forms.

Camera setup alone took five sub-steps of technical forms.

02Decision

Node canvas, guided steps.

I proposed the model that replaced the form wizard.

03Result

4 months

To ship. One of the products sales promoted most actively.

ConstraintNo direct access to end users. I iterated with developers, received client feedback through sales and support, and defined the usability tests below as next steps.

Context

Connecting video, processors and events.

IoT Unified is Sorba’s platform for managing IoT infrastructure. Its Vision node connects video sources, processes the stream and defines what the system should detect.

The task was to connect a video source, choose how to process it and configure detection. The old setup exposed technical settings before it showed how those parts fit together.

My contribution

  • Researched node-based tools and adapted the pattern to Vision.
  • Defined the canvas, tools palette and contextual configuration.
  • Designed the guided setup flow around stream processing.
  • Designed processing nodes and the Interests Zone editor.

I worked from the project manager’s requirements and proposed the node-canvas model that replaced the form wizard. I worked with developers on implementation and feasibility, and sales and support later relayed client feedback.

Problem

A pipeline hidden behind technical forms.

The previous setup used a long wizard of technical forms. Camera configuration alone had five sub-steps before Analytics and Custom Fields. Fields such as FPS, thresholds and hardware arguments appeared before users could see how the processing stages connected.

Before · a wizard of forms

  1. Start
  2. General Information
  3. Camera Configuration
    1. Information
    2. Motion
    3. Detections
    4. Records
    5. Snapshots
  4. Analytics
  5. Custom Fields

FPS, thresholds and hardware arguments came before users could see how the stages connect.

The pipeline had to be inferred across form steps.

After · guided setup around one canvas

  1. Start
  2. General Information
  3. Video Input
  4. Stream Processors Video InputProcessorsEvents
  5. Custom Fields

The whole pipeline is visible as connected nodes.

Settings open beside the selected node.

Illustrative flow in the style of a FigJam board, built from the step names in the product screens. Not a screenshot.
Previous wizard, camera configuration step: a template dropdown and several technical argument fields

Before: camera configuration

Camera settings and technical arguments spread across form steps.

Previous wizard, detections step: FPS, width, height and threshold as isolated numeric fields

Before: detections

Processing parameters presented as isolated numeric fields.

Before

A fixed sequence of forms; camera setup alone took five sub-steps.

Technical fields up front: FPS, thresholds, hardware arguments.

Pipeline structure had to be inferred across form steps.

Canvas design

One canvas where the whole pipeline is visible as connected nodes.

Predefined nodes that users reconfigure instead of building from zero.

Contextual settings alongside the selected node.

Research

Finding a visual model for a technical workflow.

I needed a clearer way to connect video inputs, processing steps and their settings. I researched how other tools use nodes and graphs to make complex workflows visible. That search led me to Blender’s Shader Editor, NodeGraphQt and PixiEditor. This was pattern research, not a study of Vision users.

Reference review — what I looked for

Blender Shader Editor showing linked nodes on a graph

Blender · Shader Editor

How visible links reveal the relationship between processing steps.

NodeGraphQt example with curved pipes connecting nodes through input and output ports

NodeGraphQt

How input and output ports make connection points explicit.

PixiEditor graph view with nodes, a layers panel and a live preview

PixiEditor · Graph View

How inputs, outputs and previews stay close to the graph.

What I adapted for Vision: a visible pipeline, predefined components and configuration in context.

Reference screenshots: Blender, NodeGraphQt and PixiEditor. © their respective owners.

Solution

Configuration around the graph.

The canvas sits inside a four-step setup: General Information, Video Input, Stream Processors and Custom Fields. It makes the processing pipeline visible while retaining a guided path through the wider task.

Vision’s Stream Processors step: four setup steps on the left, a palette of components, a canvas of connected nodes and a maximize control

  1. Guided steps

    The four-step setup stays on the left, so the canvas has a defined place in the task.

  2. Predefined components

    Video input, events and processors come from a palette, instead of being typed in as arguments.

  3. A visible pipeline

    The connections between video input, processors and events are drawn, so the order can be read at a glance.

  4. Maximize

    A control to take the canvas to full screen, added after developers found the embedded canvas too cramped.

Stream Processors step, annotated. Hover a number to match it with its note.

Why keep the wizard around the canvas?

The graph makes relationships visible, but it introduces a new interaction model. Keeping it inside the setup flow gives the canvas a defined place in the task. Next, I would test whether first-time users can connect nodes without help.

Forms only Previous setup
A fixed sequence gives users an order to follow, but leaves the pipeline’s relationships spread across steps.
Canvas only Hypothetical alternative
More room to arrange nodes, but less guidance about the wider setup task and where to begin.
Guided setup + canvas Design shown
Keeps the sequence and exposes connections. The cost is a smaller working area and a graph interaction users still have to learn.

Retrospective comparison of trade-offs. The canvas-only alternative is hypothetical; these approaches were not compared in user testing.

Design decision / 01

Keep configuration in context

Selecting a node opens its settings beside the graph. Buffer size, recording options and trigger types stay available without leaving the pipeline.

The trade-off is space: the inspector competes with the canvas. That became a concrete issue in developer review.

Raw Streamer node selected on the canvas with its inspector open beside the graph
Interests Zone editor: a camera image with drawn masks listed beside the node configuration

Design decision / 02

Define detection areas visually

The Interests Zone editor lets users draw masks over the camera image and manage them alongside the node configuration.

The image gives the mask a spatial reference. Whether people can draw, revise and interpret those areas accurately still needs a task-based test.

General Information step with a four-step progress list on the left

Keep the wider task guided

Four steps frame the canvas as one stage of setup, with the current stage visible.

Tools palette grouping inputs, events and processors by type beside the canvas

Make processing tools identifiable

Inputs, events and processors are grouped by type in a palette beside the canvas.

Iteration

Refining the design with developers.

I worked with developers through a loop of design, implementation, feedback and revision, which refined the interaction and what the team could build.

  1. 01

    Design

    Explore interactions and map the configuration flow.

  2. 02

    Build

    Work with developers to implement the flow.

  3. 03

    Feedback

    Review the working interface and technical constraints.

  4. 04

    Iterate

    Revise the design and repeat the loop.

Developer feedback → design changes

ITERATION 1

Give the canvas more room

Raised

The developers found the embedded canvas too cramped.

Changed

I added a way to maximize the canvas to full screen.

The embedded canvas in the Stream Processors step, with the new expand control at the top right of the canvas
Embedded, with the new expand control at the top right.
The maximized canvas in a full-window dialog titled Stream Processors, with the tools palette, the graph, the Interests Zone editor and the inspector, and a Close control
Maximized: the whole window for the canvas, with a Close control.

ITERATION 2

Keep related forms together

Raised

The interface needed to display two related forms at once.

Changed

I placed the forms side by side and added a close control to the second one. I checked feasibility with the developers before committing to the layout.

One form open beside the canvas: the inspector with the Raw Streamer settings
One form at a time: the inspector.
Two related forms displayed side by side: the Interests Zone editor and the inspector, the first with a close control
Two related forms side by side, the Interests Zone one with a close control.

Outcome & next steps

Shipped in four months.
Next: measure usability.

Vision shipped after four months. Sales and support, who worked directly with clients, relayed positive feedback, reported good customer acceptance and said Vision was one of the products the team was promoting most actively.

The canvas also changed how flows get built. Before, every node was configured one by one, about 10 minutes per node. Now a configured node can be saved, reused in the graph and adjusted in place, so teams start from a base of predefined nodes. That 10-minute figure is a team estimate, not a measurement.

Next, I would complement that qualitative feedback with measures of setup completion, errors and requests for help.

Before, we had to build the flow node by node, about 10 minutes for each one. With nodes in the graph we can save configured nodes, reuse them directly and adjust them in the same graph, so we start from a base of predefined node types and save that time.

Javier RodriguesDeveloper at Sorba.ai

4

months to launch

5

camera sub-steps in the earlier wizard

≈10 min

to configure each node by hand, before reusable nodes (team estimate)

What I would test next

Proposed validation. I would first learn who configures Vision and how often, then observe representative setup tasks.

  1. Build a pipeline

    Ask someone to connect a video source and predefined processors. Observe completion, incorrect connections and requests for help; compare with the previous wizard where feasible.

  2. Edit a setting in context

    Ask them to find a node’s inspector and change a setting. Check whether they can explain which part of the pipeline they changed.

  3. Work with a larger canvas

    Ask them to edit an Interests Zone with related forms open. Watch whether they find the maximize and close controls, and where space still gets in the way.

Reflection

What I learned.
What comes next.

What I would do differently

Bring users into the process earlier. Developer feedback helped refine feasibility, but user sessions are needed to understand whether the canvas works for people without a technical background.

What I took away

This was my first project with nodes and graphs. Studying other tools helped me see how a canvas could make relationships and configuration visible in a web product.

Let’s talk about
your next product.

Email me