Based in New York City
Multidisciplinary Designer
Visual / 3D / UI / UX / Motion

Clients include:
Google
Meta
Fantasy
Bloomberg
Elephant
LinkedIn
and more

Work
Photography
Instagram

Résumé
knh4110@gmail.com
347 920 8623

Robots.build
Bedrock Robotics builds autonomous excavators for construction sites. As the sole designer, I lead the design of Worksites Portal, the partner-facing platform where construction teams author and monitor excavation tasks, translating complex machine operations like grading and trenching into a task authoring flow that operators can trust. This spans interaction design, motion, and the design system underpinning it.

Product Design
Interaction Design
Design Systems
Motion Design

Product Designer | Namh Kim
Product Manager | Stuart D.
Software Engineers | Nick A., Maxim M., Ansel V. and more.

Context

Bedrock retrofits standard excavators to operate autonomously. The machines can grade, trench, and move material on their own, but someone still has to tell them what to do.

That someone is a site foreman, not a software user. They think in stakes, grades, and spoil piles. Worksites Portal is where that intent becomes a task the machine will execute, unsupervised, on real ground.

Image: a photo of the machine working, or a foreman at a laptop in a trailer. Documentary register, not product-shot. If you have nothing, skip it — this section is fine as text.

The problem

Authoring a task is not filling out a form. The operator is describing a physical outcome in space: a surface at a target elevation, a trench along a line, a cut relative to where the machine is standing right now.

Two things make it hard. The same intent can be expressed in absolute terms (grade to 412.5 ft) or relative ones (cut 3 ft below current grade), and different operators reach for different ones. And unlike most software, a misread number doesn't produce a bad output — it moves earth.

Image: one diagram. A simple section view of ground with the two framings drawn on it: an absolute elevation datum on one side, a relative offset from current grade on the other. This is the single most valuable image on the page and probably worth making from scratch rather than screenshotting.

Task Authoring

The flow branches early. Choosing a task type determines what the operator is asked for next — an absolute target pulls in site datum and elevation, a relative one anchors to the machine's current position.

The design goal was for that branch to feel like one flow rather than two. Shared structure, shared language, shared confirmation step, with only the parameters that actually differ changing between them.

I built the flow as interactive HTML prototypes so the team could walk it at speed instead of reading a spec. Most of the real decisions got made standing over a laptop with a controls engineer.

Image: the flow itself — a horizontal sequence of screens showing the branch, plus a screen recording of the prototype if you can clear it. The recording is the strongest asset you'd have on the whole site; it shows motion and interaction at once, which static work can't.

Designing for uncertainty

Autonomy state is reported, not set.
The machine card shows whether a machine is in autonomous mode. It looks like a status, not a control, because it is one — autonomy is entered at the machine, by a person standing next to it. Making it tappable in the portal would have implied a kind of remote authority the system deliberately doesn't grant.

Image: close crop of the machine card, annotated.

Confidence travels with the number.
Elevation readings depend on positioning quality that varies with sky view, equipment, and interference. Rather than hiding that, the card carries a signal indicator next to the reading, so an operator can tell the difference between a number to trust and a number to re-check.

Image: the indicator in both states, side by side. Small, tight crop.

Getting the words right.
A recurring part of this work is settling what a term actually means before designing how it looks. Whether a target grade is a single value or a tolerance range, for example, is a controls question before it's a UI question, and answering it wrong makes a clear-looking screen that lies.

Image: none needed. Text-only block is a good rhythm break here.

Monitoring

Once work is running, the machine page is where it's watched. Overview carries live status and a camera feed inline; Today, Cameras, and Health go deeper when something needs checking.

The camera feeds deliberately sit here rather than inside authoring. Authoring is about intent; watching is about verification. Keeping them apart kept both simpler.

Image: the machine detail page, with the camera view and the Front/Rear/Left/Right selector visible.

System and craft

As the only designer on a team of [7+] engineers, the system had to do the work I couldn't do by hand. Components, tokens, and motion patterns are built so that new surfaces come out consistent by default.

Image: a component sheet or token overview, plus one or two short motion clips. Your motion work is a differentiator against most product designers and it's currently invisible on the site.

Outcome

[In the field on [N] machines across [N] sites] — or, if no numbers are clearable: Worksites Portal is in active use by Bedrock's partner crews, and continues to expand as new machine capabilities ship.

Image: a closing wide shot — machine on site at golden hour, or the portal in situ. Mirrors the hero and closes the page.