Skip to content
Lucas Licht Pradillo
Portrait of Lucas Licht Pradillo.

Product & industrial designer | Graz, Austria

I design where hardware and interface meet, so the seam between them disappears.

Graz, Austria | MSc Industrial Design, TU Eindhoven | Open to new roles

I design products end to end: the interface, the interaction and the system underneath. Industrial design is where I trained, and I bring its feel for clarity and craft to work that has to feel obvious, on a screen or in your hand.

At Mercedes-Benz Design I spent my master’s thesis and six more months in the Advanced UX studio, first on Glide, then on a prototyping system that lets the team test a new physical interaction idea within hours. Now I design production software at LearningSuite, which has more than 800,000 users. One of my projects there is Modular AI-Agents: the agents people build with it answer around 80,000 questions a month.

Currently

  • Product designer at LearningSuite in Graz, on the learning platform and the SalesSuite CRM
  • A new sales product for LearningSuite, designed from scratch and private for now
  • Both company websites, designed and built in Webflow
  • Sivun, my own meeting recorder and the app it feeds

Datasheet

Rev. 2026

Unit

Designation
Product & Industrial Designer
Discipline
UX | Physical & digital UI | Interaction | Prototyping
Origin
German / Spanish
Deployed
Graz, Austria

Field record

2025–
LearningSuite Flexco, Graz: Product development, UX/UI
2025
Mercedes-Benz Design, Sindelfingen: Werkstudent, Advanced UX Design | The prototyping kit
2024–25
Mercedes-Benz Design, Sindelfingen: MSc thesis, in studio
2021–23
LLP Renderings: Self-taught 3D, freelance product renders & animation
2021
Smart-Ship B.V.: Azimuth control ergonomics

Certification

MSc ’25
Industrial Design: TU Eindhoven (Research, Design & Development)
BSc ’21
Industrial Design Engineering: The Hague University

Toolchain

Design
Figma | ProtoPie | Webflow | Adobe Creative Suite
3D / CAD
Fusion 360 | Blender
Code
Arduino (C++) | Python | Processing | ESP32 / I²C
AI / Build
Claude Code | Cursor | ComfyUI

Protocols

Languages
German C2 | English C2 | Spanish C2 | Dutch B2 | Swedish (actively learning)

Full record

Curriculum vitaePDF | 0.5 MB

Want to know more?

A tool for the tool.

At Mercedes-Benz Design, I needed to try interaction ideas on real controls, and fast. So I built a kit: components plug into an ESP32 and switch on from a web page the board serves itself, and an idea can be wired up and tested the same afternoon.

Inputs
Motor fader | Rotary encoder | Linear encoder | Buttons | Potentiometers | Touch-sensitive surface
Outputs
Vibration motors | LED strips | Servo motor | Piezo buzzer
Bus
I²C plus a 5 V line over a 6-pin JST-SH daisy chain | PCF8574A expanders, ADS1115 converters and a PWM driver
Controller
ESP32, serving its own control page | two-way link to ProtoPie Connect

One interface for every part. The kit takes the parts you reach for when prototyping a control: motor faders, rotary and linear encoders, buttons, potentiometers and touch-sensitive surfaces on the input side. On the output side there are vibration motors, LED strips, a servo motor and a piezo buzzer.

Out of the box, none of them share an interface. Each wants its own pins and its own wiring. So I put every component on I²C, each through a chip that suits it: a digital expander for buttons and encoders, an analog converter for potentiometers and the fader, a PWM driver for the servo. The LED strips got a ready-made controller module on the same bus. They all share the same two wires, each answers to its own address, and the ESP32 talks to every one of them the same way. That shared interface is what made the kit modular. A new part gets an address and works next to the others.

Two small SOIC chips wired directly to a breadboard with loose jumper wires.
Before. These chips made the kit possible, but they’re tiny and miserable to wire by hand. I was testing three types at once. Only one came ready-mounted on a small breakout board with breadboard pins. The first of the others went in dead-bug style, with wires soldered straight onto their little legs. I broke a few that way. It got results, just slower than I wanted, so I took a step back: before trying out more expander boards, I needed a way to build every one of them the same way. That’s where the carriers came from.
Back side of three clear 3D-printed carrier boards with red, green and black wires routed through slots.
The carrier. A clear printed base holds the chip in a pocket and routes the wires through slots on the back: red for power, black for ground, green for the bus. Every module gets built the same way.
Three clear 3D-printed carrier boards, each holding a chip, labelled 0x38, 0x39 and 0x3A.
Addressed. Each carrier has its I²C address printed into it, 0x38, 0x39 and 0x3A, so you can tell them apart without a multimeter or a datasheet. The addresses also had to be planned. Most of these chips only offer a handful, four to eight, and no two parts on the bus can share one, so I picked them so the expanders, the analog converters and the PWM driver never overlapped.

Photography wasn’t permitted at the Mercedes-Benz Design Center. These are the only images of the kit’s development.

Click together. With the carriers, every module could be wired up and tested the same way, and that gave the kit a base to build on. The next question was how modules attach to each other. The bus itself only needs four wires: power, ground and the two I²C lines. I used small 6-pin JST-SH connectors and gave one of the spare pins a 5-volt line, because some components need more than the 3.3 volts the ESP32 runs on. Every module carries the same connector, so they daisy-chain: each one clicks into the one before it, or plugs straight into the base unit that holds the ESP32. The first set of components came out of that, among them a four-button pad with Cherry switches, all four wired to a single expander.

The control page. The ESP32 serves a small web app where you switch components on and off as you plug them in. Each component’s code lives in its own module, pulled in with one #include line, and the board only starts up the ones you’ve switched on. That way the ESP32 knows exactly which inputs and outputs it has, and it exchanges values with ProtoPie Connect in both directions, so the physical controls can drive a ProtoPie prototype and the prototype can drive the outputs in turn.

An I²C address is normally invisible: it lives in the code and in how three pins are tied. Printing it into the part makes it readable at a glance. It’s a small case of something I care about in every project: what a system is doing should be readable in the object itself.