the thing they don't tell you about designing for an industry you know nothing about

every role I’ve taken, I walked in knowing almost nothing about the industry.

video editing software. fintech. CRM and operational management platforms.

different markets. different users. different problems.

same panic on day one.

there was always some context — a founder walking you through their vision, a CTO explaining why they needed a redesign. but never enough to feel fully ready. you pick up the vocabulary mid-project. you ask questions mid-iteration. you figure it out as you go.

so that’s what I did.

first iteration. wrong. redesign. closer. iterate again. until the pattern revealed itself.

and it always revealed the same thing underneath.

tables-panels-modals-drawers-forms

every industry, every product, every “complex enterprise platform” — it’s the same fundamental pieces. the industry just changes what lives inside them.

CRM workflows are just tables with different columns. operational dashboards are just panels with different data. AI tools are just modals asking different questions.

yes, it simplifies things. but it gets you started.

once I saw that, the panic stopped.

the domain knowledge comes through the designing. not before it.

what actually changes between industries

the vocabulary. the stakeholder opinions. the number of Figma comments. the way engineers think about the problem versus the way you do

at one company I learned craft the hard way. a founder who hammered on details I didn’t understand yet. spacing. hierarchy. type. things that felt pedantic in the moment but rewired how I see interfaces permanently.

at another I learned systems thinking. a product so interconnected that designing one screen without understanding ten others would break everything. I stopped seeing UI as individual screens and started seeing it as one continuous experience.

both painful. both necessary.

the panic on day one isn’t a signal that you’re wrong for the role. it’s a signal that you’re about to learn something.

the thing nobody told me about design systems

I built two of them. from scratch. in industries that had never thought about design systems before.

not because someone asked me to. because without a foundation nothing else works.

vibeocoded elements pile up. components gets built in six different ways. the product starts feeling like three different products duct taped together.

a design system isn’t a deliverable. it’s the thing that makes everything else possible.

most companies don’t realise they need one until AI starts generating their UI and suddenly nothing looks like it belongs together.

by then it’s too late to build the foundation. you just inherit the chaos.

the companies that will win with AI aren’t the ones who prompt the best. they’re the ones who built the foundation before the chaos arrived.

what I know now that I didn’t know then

working with developers properly is a skill nobody teaches you.

it’s not about handoff. it’s about shared language.

understanding what “out of scope” actually means. knowing when to push back and when to simplify. learning how a comment in figma becomes a PR becomes a feature becomes something real people use.

that translation work — between design thinking and engineering reality — is where most products succeed or fail quietly.

most designers treat developers like a delivery service. the best designers treat them like collaborators who think differently.

once I understood that, everything got easier.

lately I’ve been getting into Claude and building interfaces from scratch myself. and something funny happened.

I started hitting the exact same pain points the developers always raised.

empty states. error handling. loading skeletons. edge cases I had completely ignored because I was so focused on the synergy of the product — the happy path, the beautiful flow, the vision.

building it yourself humbles you fast.

but it also gave me a new superpower. the ability to build a design system, ship real interfaces and learn any new tool or framework quickly.

design and engineering are not separate disciplines anymore. the best work happens in the overlap.

also — light gray text is never the answer. I will die on this hill. 😄

the honest thing

you don’t need to know the industry before you start.

you need to start in order to know the industry.

walk in with your basics. widen the context. let the first iteration be wrong. let the redesign teach you something.

every complex product eventually reveals its simplest form.

tables. panels. modals. drawers. forms.

and then how you shape those basics — how you make them feel native to a specific world, how you make a user feel like the software was built exactly for them — that’s where the real design work lives.

that’s not something AI generates.

that’s something you develop.

the domain knowledge will come. the design thinking was always yours.