How to Become a Design Engineer: Start With One Pull Request
No engineering degree needed. A designer who now ships React code explains how to become a design engineer in tech, with a stage-by-stage roadmap and real examples.
How to become a design engineer: pick one platform (React for web or SwiftUI for iOS), rebuild your own designs in code with every state included, learn Git and pull requests, and ship small real things until a team trusts you to merge interface code. You do not need a degree in engineering. You need proof that you can make design decisions and land them in production. I moved from Lead Product Designer to design engineer on ViewStats, the creator platform built by the team behind MrBeast, by doing exactly that: designing, prototyping, building React components and opening pull requests. This guide is the path I would give a designer or a front-end developer who wants the same role in tech.
First, which design engineer do you mean?
Search "how to become a design engineer" and half the results are about civil or mechanical engineering: CAD, tolerances, licensing exams. That is a real job, and it is not this one.
In software, a design engineer is the person who owns the interface from idea to production. They design the flow, prototype the interaction and write the front-end code that ships. If you want the full definition and how the role compares to a product designer, read my pillar guide on what a design engineer is in software. This post is only about the path into it.
One more thing before the steps. Nobody hands you this title on day one. In my case the role grew out of a product design job. I kept getting closer to the code until working in the codebase became the fastest way to get the product right.
How to become a design engineer in tech: the two doors
There are two common starting points, and they need different work.
From design. You already have taste, flows and user empathy. You are missing the ability to read a codebase, write components and survive a code review. This is the door I came through.
From front-end engineering. You already ship code. You are missing the design judgment: why an interaction feels right, when to cut a feature, how to frame a problem before building anything.
The trap for designers is learning a little code and calling it done. The trap for engineers is learning Figma shortcuts and calling it design. Both sides have to reach the point where the other side trusts their work without translation.
The roadmap, stage by stage
This is the order I would follow. Each stage ends with something you can show, because in this role proof beats claims.
| Stage | What to learn | Proof to show |
|---|---|---|
| 1. Pick a platform | React and TypeScript for web, or SwiftUI for iOS. One, not both. | A small app running locally that you built yourself |
| 2. Rebuild your own design | Layout, components, hover, loading, empty and error states | A live link next to the original design file |
| 3. Learn the team workflow | Git, branches, pull requests, reading code you did not write | A merged pull request, even a tiny one |
| 4. Own a component | Design tokens, variants, accessibility, documentation | One design system component, designed and coded by you |
| 5. Add feel | Motion, gestures, physics, sound where it helps | An interaction people want to replay |
| 6. Ship to users | Deploying, measuring, iterating after launch | A real product or feature with users and a result |
You can move through stages 1 to 3 in parallel with a full-time design or engineering job. Stages 4 to 6 usually happen inside a team, which is why the next section matters.
Get into the codebase at your current job
The fastest route is rarely a new job. It is asking for access where you already work.
At ViewStats I was leading design across web, mobile, the Chrome extension, growth and AI experiences. Handoff was the slow part: a design was finished, then it took rounds of back and forth to ship it the way it was meant to feel. So I started working in the codebase with Cursor, Claude Code, React, TypeScript and GitHub. I designed, prototyped, built React components, opened pull requests and reviewed implementation. The iteration cycles got dramatically shorter. The ViewStats case study covers the product side of that work.
If you want to try this, start where the risk is low:
- Copy fixes, spacing and color token changes
- Empty states and loading states nobody has prioritized
- A small component inside the design system you already maintain in Figma
Small pull requests that are easy to review build trust faster than one big impressive one. Engineers merge what they can understand. GitHub's own guide to pull requests is worth reading once, slowly, before your first one.
Use AI as a tutor, not a vending machine
AI coding tools changed how fast a designer can get into code. They also make it easy to fake it.
The difference shows up in code review. If you paste whatever the tool generates, you cannot explain your own pull request, and the trust you were building disappears. If you ask the tool why the code works, change it yourself and then ask what you broke, you learn faster than any course I know.
My 17 AI design experiments are built mostly with Figma, Claude and the Figma MCP, plus SwiftUI, WebGL, three.js and physics engines. Each one is a working build, not a mockup. That is the point: they are practice reps for design engineering, where every effect has to run on a real device. If you want to see what one of those reps looks like in detail, I broke down a shatter-to-unfreeze card interaction and a 3D configurator with live physics.
Which tool to start with matters less than people think. I compared the two I use most in Claude Code vs Cursor.
Learn the platform properly, not just the prompts
Prompts get you a first draft. Fundamentals get you a merged pull request. For web, work through the official React documentation until you understand state, props and effects without looking them up. For iOS, Apple's SwiftUI tutorials are the best free starting point I know.
What to skip at the beginning: backend architecture, databases, DevOps. A design engineer needs to be fluent at the interface layer and respectful of the rest. You need a strong engineer next to you regardless, someone who owns performance, data and architecture.
What not to skip: accessibility. A designer who codes an interface that a screen reader cannot use has shipped a bug with good taste.
Build a portfolio that runs
A design engineer portfolio full of static screenshots is a contradiction. Hiring managers for this role want to click something.
- Link live builds, not only images.
- Show the design file and the shipped result side by side.
- Explain one decision per project: why this motion, why this state, why this cut.
- Include at least one thing you shipped with a team, through review, to real users.
Side projects count, but shipped team work counts more. One merged pull request on a real product says more than ten solo demos, because it proves you can work inside someone else's constraints.
Mistakes I see on the way in
Learning everything at once. React, SwiftUI, three.js, shaders and backend in the same month. Pick one platform and get boringly good at it.
Treating code as the goal. The goal is still the product. At ViewStats the biggest wins came from understanding the user, like the onboarding work that took channel connection from 13% to 65%+ (I wrote about it in onboarding UX best practices). Code made those changes faster to ship. It did not find the insight.
Skipping the team part. Design engineering is a collaboration role. If engineers do not want to review your code, you are not there yet.
Waiting for permission. Ask for codebase access. The worst answer is no, and many teams say yes because handoff hurts them too.
Where this advice does not apply: if your company is still searching for what to build, polish is not the bottleneck. A product designer who talks to users is worth more at that stage than one who writes components.
FAQ: becoming a design engineer
What qualifications do you need to be a design engineer in software?
No specific degree is required. Teams look for proof: a portfolio of live builds, merged pull requests and a clear design process. A computer science or design degree helps, but I have not seen it replace shipped work in a hiring decision for this role.
How long does it take to become a design engineer?
It depends on where you start and how much real code you ship, so I will not give you a number. A better question is how soon you can get your first pull request merged on a real product. Make that your first milestone.
Should a designer learn React or SwiftUI first?
Learn the platform your product or target companies use. Web teams hire for React and TypeScript, iOS teams for SwiftUI. If you have no constraint, React gives you the most job options, and SwiftUI gives you very fast feedback on native feel.
Can AI tools make you a design engineer without learning to code?
No. AI lowers the entry cost, but you still have to read, explain and defend your code in review. The tools make a learning designer much faster. They do not replace understanding.
Is a design engineer the same as a front-end developer?
No. A design engineer makes design decisions and writes the code. I broke down the difference in design engineer vs front-end developer.
Your first step this week
Take one screen you designed and rebuild it in code, with its empty, loading and error states. Put it online. Then ask your team for codebase access and pick the smallest visual fix in the backlog. That pull request is the start of the role.
If you are on the other side and your team needs someone who designs the product and ships the interface, you can work with me as your design engineer, or look at my product design work first. And if you are deciding between paths, my take on whether AI will replace product designers might help you choose.
hello@ayoubka.com
If you have a web or mobile app idea in mind or you need some advice about product design, feel free to get in touch ✉️