Neta-lee ArtziProduct Designer
Back to Skyline Robotics

Skyline Robotics

Building Onboarding

Redesigning how new buildings get into the system

Before a robot can clean a single window, every building has to be mapped with millimeter-level precision: facades by orientation, vertical drops, and the dimensions of every window.

I redesigned a two-person, three-tool workflow into a single operator interface. The operator who measures the building now enters the data directly, without a developer in between.

  • B2B SaaS
  • Admin UX
  • Workflow redesign
  • Process automation
Role
Lead Product Designer
Timeline
2025
Users
Field operators
Platform
SaaS Platform

Context

The existing workflow

The problem wasn’t the robot. It was the multi-day process of turning a physical building into data the system could read.

  • 01

    The operator maps the building on-site

    At least a full day: facades by orientation, drops counted, window patterns verified with the building’s cradle.

  • 02

    Pen, paper, then Excel

    Field notes are typed into a spreadsheet template, disconnected from the system it was meant to feed.

  • 03

    A developer re-enters everything

    Another full day copying Excel rows into the Engineer UI. No engineering knowledge needed, but engineering time spent.

  • 04

    Errors surface at deployment

    If the robot’s scan doesn’t match the data, it crashes. A few cm off makes it run much slower. Fixes need remote intervention from Israel.

The problem

Two people. Three tools. One point of failure.

Every handoff was another chance for error, and none of them were caught until the robot was already on the building.

  • Data entry errors

    Copying from Excel into the Engineer UI by hand invited mistakes. A misplaced decimal, 1.2 becoming 12, could send the robot on the wrong trajectory.

  • Developer bottleneck

    Every new building needed a full day of developer time for a task that required no engineering skill.

  • No direct ownership

    The operator, the person who physically measured the building, had no access to the system. Their data passed through two handoffs before it reached the robot.

Research and insights

What the research showed

I analyzed the full data chain, from operators’ field notes to the Excel files developers received, and interviewed developers and field operators to map the edge cases. Four insights came out of it.

  • Insight 01

    Most buildings are uniform. Some have patterns.

    Most drops have identical windows. Some repeat a sequence, some have exceptions on certain floors. The old workflow treated every window as a unique entry anyway.

  • Insight 02

    Time loss compounds across the relay

    One day to measure, another day of developer transcription: a two-day minimum, not because the data was complex, but because two people did sequential manual entry.

  • Insight 03

    Operators think in facades, not row numbers

    On-site, operators map by orientation, with setbacks treated as sub-facades. The spreadsheet forced them to translate that into abstract rows with no visual anchor.

  • Insight 04

    The developer was a relay, not a contributor

    Developers rarely changed the operator’s data; they copied it. Removing them from the loop wasn’t risky. It was the fix.

The key insight

The fix wasn’t smarter validation. It was giving the operator direct access to the system they were already feeding.

Key design decisions

One interface. One person. No middleman.

Three decisions turned the relay into a direct connection between the operator and the system.

01

The facade is the main view

Problem: Operators map buildings by facade and drop, but the Engineer UI was a flat table of row numbers, with database names like “Ws.Width.Height”.

Decision: A large schematic of the selected facade sits at the center, with every drop drawn as a column of windows. Clicking a drop opens it in a side panel with plain labels, like “Window width (m)”. Facade tabs match the physical orientations, and the building details stay on top and collapse when they’re done.

Why: An operator working on “Facade 2, Drop 3” sees exactly where they are, and a wrong value looks wrong on the facade before it reaches the robot.

Trade-off

The table becomes secondary and is collapsed by default. Some operators like to scan every number before saving, so it stays one click away under the facade. I still rejected a step-by-step wizard: fieldwork isn’t linear, and operators switch facades when the sun is in their eyes.

Facade 1 schematic with twelve drops and the Edit Drop 2 panel
02

One drop, duplicated across the facade

Problem: On most facades every drop is the same, apart from the corners. Some drops repeat a window sequence (A-B-C-B), and some have single exceptions, like a lobby floor.

Decision: The operator enters one drop, types its window sequence and clicks a window to mark an exception. “Duplicate Drop” adds as many copies as needed, and any drop can be dragged to a new position, so a corner drop is copied and moved to the other end. Copies remember their source: when a drop with copies is saved, the operator chooses how far the change goes.

Why: A 12-drop facade is one drop, a few duplicates and one drag. A typo found after duplicating is fixed once, not twelve times.

Trade-off

Copies that remember their source add a concept to learn. To keep it light, the question appears only when a drop has copies; a single drop saves without it.

Window sequence field and a window marked as an exception
The operator types any window sequence and clicks a window to mark an exception.
Duplicate Drop dialog: drop to copy, number of copies, and where to place them
Duplicate Drop adds copies right after the drop. Any drop can then be dragged to a new position.
Dialog asking which linked copies a change should apply to
When a drop has copies, the operator chooses how far a change goes.
03

Soft checks, and whole facades copied

Problem: A misplaced decimal, 1.2 becoming 12, could send the robot on the wrong trajectory, and it was only caught at deployment. The facades of a building usually repeat, but each one was built from scratch.

Decision: Soft checks flag a value far out of range, or a drop that doesn’t reach the roof, and offer the likely fix. They never block the save. A finished facade is copied to the other sides with “Duplicate Facade”, each side with its own number of drops.

Why: The operator is the expert on site. A gentle check catches the typo without second-guessing a building that really is unusual, and a whole tower is set up from one facade.

Trade-off

Because the checks never block, an operator can still save a wrong value. The warning stays on the drop and on its facade tab until someone looks at it.

A soft check: “12 m is unusual for window width. Did you mean 1.2 m?” with a Use 1.2 m button
A 12 m window width is flagged, with the likely fix one click away.
Duplicate Facade dialog copying drops to the other sides
Duplicate Facade copies the drops to the other sides, each with its own number of drops.
A shorter facade drawn shorter in the schematic and in the building footprint
A shorter side is drawn shorter, on the facade and in the footprint.

Outcome

What changed

The new flow is in use: operators now onboard buildings directly, on desktop. The changes below come from the redesigned flow itself; the metrics after them are what I’d track to confirm it works over time.

  • People in the loop

    2 → 1

    The operator who measured the building enters the data. No developer relay.

  • Entry per drop

    1×

    A drop is defined once; duplicates and window sequences handle the repetition.

  • Developer data entry

    0 hours

    Developers are out of the data-entry loop and back on product work.

  • Before

    • Operator measures on-site with pen and paper
    • Data typed into an Excel sheet
    • Handoff to a developer
    • Developer re-enters it into the Engineer UI
    • Errors discovered at deployment

  • After

    • Operator measures on-site
    • Operator enters data directly in the Admin UI
    • A visual of the facade confirms the structure
    • Duplicates and sequences handle repetition
    • Operator saves, and the building is ready

What I’d measure next

  • Time to configure

    From the operator’s arrival to a saved, system-ready building. Baseline: at least two days. Target: same day.

  • Duplicate adoption

    The share of buildings set up mostly with Duplicate Drop and Duplicate Facade.

  • Deployment incidents

    Robot crashes and slowdowns caused by mismatches between the scan and the data, before vs. after.

  • Developer hours reclaimed

    Engineering hours per quarter no longer spent on data entry.

Reflection

The interface was never the blocker. The relay was.

The most important decision wasn’t a UI component. It was changing who enters the data, and designing the interface to make that safe. The data model didn’t change; the workflow did.

What I’d explore next

  • Whether operators find drag to reorder on their own, or need arrows on the selected drop.
  • Whether copies should stay linked after duplicating, based on how often operators fix a value afterwards.
  • How the soft checks feel on a building that really is unusual, so they help without nagging.
  • Design for tablets in the field, the planned next step. Today the flow runs on desktop.

Let’s talk

Open to product design roles in B2B and complex systems. Happy to talk.