UX/UI Design Student
Karsten van Vooren
I'm a creative and social designer with a passion for UX/UI and web design, and I build what I design.
Selected work
Recent projects
View all work →What I do
I start from user flows and low-fidelity wireframes, then move into visual design once the structure actually works. Everything happens in Figma, with fast iteration so bad ideas get killed early instead of after they're built. The goal is always an interface that reads as obvious, not just one that looks nice.
Typography, color, spacing, and components get defined once, in a shared library, instead of redrawn on every screen. That keeps a product visually consistent as it grows past the first few screens, and makes it much faster to design and build new features later without reinventing decisions that were already made.
Mostly React and Next.js on the frontend. I like being the one who builds what I designed, since it keeps the two honest. On the backend I've worked with Node.js, Express, and MongoDB when a project needs its own API, authentication, or a database, most recently on the KSK Beveren app.
Somewhere between a click-through Figma prototype and a full production build, there's a working version that's real enough to actually test with people. I build that middle step often, since it's usually the fastest way to find out if an idea holds up before committing to a full build.
How I work
Before opening Figma, I try to get clear on who this is actually for and what they're doing today instead of using this product. That means talking to users where possible, looking at what already exists, and writing down the actual problem in one sentence. If I can't do that, I'm not ready to design yet.
Wireframes come first, so structure and flow get settled before any visual decisions. Then visual design, building or extending a small design system of colors, type, spacing, and components along the way, so the product feels considered rather than assembled screen by screen.
I show my designs before they're finished: to teachers in feedback sessions, to classmates, and to users when I can. Fresh eyes catch what I've stopped seeing, and changing a Figma screen is much cheaper than changing a built one.
This is where the design becomes real: working code, real data, real edge cases. I try to stay close to the original design intent instead of quietly cutting corners under time pressure, and I flag it explicitly when a technical constraint means something has to change.
After a project I write down what went well, what didn't, and what I'd change. That's where I learn the most.
About
UX/UI Design Student at
AP Hogeschool Antwerpen.
Good design isn't just how it looks. It's how well it works.

