From Designer to Design Engineer: A Practical Guide for Getting Started

by

Transitioning from designer to design engineer can feel like stepping into a whole new world—new tools, new workflows, and a lot of unfamiliar terminology. If you’re a visual designer who’s learning to contribute code, this guide is for you.

Whether you’re just starting to open GitHub Desktop, commit your first lines of code, or navigate your first Merge Request (MR), this post covers the essential tools, common terms, and best practices to help you grow with confidence.

What Is a Design Engineer?

A design engineer is a hybrid role. You bring UI designs to life through code—typically using frontend technologies like React and Tailwind CSS. Your mission is to ensure that designs don’t just look good in Figma but also feel great in the browser.

You’re not expected to be a full-stack expert. Instead, you’re focused on building reusable UI components, tightening design-to-dev workflows, and solving small, visual bugs that make a big difference.

Tools You’ll Need to Get Comfortable With

Cursor

Cursor is an AI-powered code editor built on top of VS Code. It integrates Git and GitHub seamlessly and offers smart autocompletion and inline suggestions. It’s great for juniors—especially designers—because you can quickly generate code based on plain language and edit with confidence.

GitHub Desktop

If you’re not ready for command-line Git, GitHub Desktop is your best friend. It lets you:

  • Clone repos
  • Create branches
  • Commit changes
  • Open Pull Requests (PRs)

The UI is intuitive and removes much of the early friction.

Glossary of Common Terms

  • MR (Merge Request) / PR (Pull Request): A request to merge your code into the main project. Same thing, different platform (GitLab uses MR; GitHub uses PR).
  • Branch: A copy of the codebase where you can safely make changes.
  • Commit: A snapshot of your changes. Try to write clear commit messages like fix: adjust button padding on mobile.
  • Diff: The visual comparison of code changes between commits or branches.
  • Linting: Automated rules that format your code and catch errors before review.
  • CI/CD: Automated processes that test and deploy your code.

Practical Tips for Designers Writing Code

✅ Do: Keep Your PRs Small

A small PR is easier to review and merge. Try to limit changes to one purpose: fix a button, refactor a component, or update spacing—not all three.

Why? Small changes reduce the chance of bugs and speed up review cycles.

❌ Don’t: Reassign Variables

If you’re using const and then trying to reassign, consider if you really need to. In most cases, clarity wins. Avoid code like this:

let styles = 'text-gray-500';
styles = 'text-blue-500'; // Don't do this

Instead:

const styles = isActive ? 'text-blue-500' : 'text-gray-500';

Why? It’s easier to read and reduces bugs from unexpected state changes.

✅ Do: Use clsx for Conditional Classes

If you’re writing Tailwind and have multiple conditional classes, use the clsx library:

import clsx from 'clsx';

const buttonClass = clsx(
  'text-sm font-medium',
  isActive && 'bg-blue-600',
  isDisabled && 'opacity-50 cursor-not-allowed'
);

Why? It keeps your class logic clean and readable.

✅ Do: Ask for Feedback Often

As a junior, don’t wait for everything to be “perfect.” Open a draft PR and ask for early feedback. Use comments to highlight where you’re unsure.

Why? You’ll learn faster and reduce rework later.

❌ Don’t: Tweak UI Without Checking the System

Design systems exist for consistency. If you’re changing a component’s padding or font-size, make sure you’re not deviating from existing tokens or styles.

Why? It keeps the product consistent and scalable.

✅ Do: Read the Code Around Yours

If you’re editing a button, look at how other buttons are built. Reuse patterns rather than reinventing them.

Why? Consistent code is easier to maintain and feels more intuitive to your team.

Extra Resources for Design Engineers

Leave a comment