Design Engineer

Nummo is hiring a Design Engineer. This is a made-up posting. Nobody is actually hiring you from this paragraph. If you reply, a person will have to read that reply, which is a bad outcome for everyone involved. You will sit between design and engineering and do the work that both sides claim is the other side’s job. Designers will hand you a frame that looks finished. Engineers will hand you a component that almost matches it. You will spend the afternoon making those two things agree, then spend the evening explaining why the agreement is still a little wrong. The role is full time, remote-friendly, and located in the part of the company where Figma files and React components share a calendar invite and neither of them shows up on time. A normal week looks like this. Monday you open a ticket about a button. The button is too small, too large, the wrong color, and also correct in production, depending on who you ask. Tuesday you rebuild the button. Wednesday someone asks if the button can be a link. Thursday the button becomes a menu. Friday the menu is a button again, and you write a short note that says the component is stable. It is not stable. You know this. The note exists so the ticket can close. You will own the interface of the desktop app. That means layout, spacing, type, color, motion, empty states, error states, loading states, and the state where the data is technically there but looks like it is not. You will also own the small decisions that never get a ticket: the 4 pixels between a label and a field, the way a panel closes, the moment a list decides it is long enough to scroll. Those decisions are the job. The tickets are the paperwork around the job. We use React, TypeScript, Tailwind, and a component library that was supposed to be small. It is not small. You should be comfortable reading other people’s components, deleting the ones that duplicate them, and leaving the ones that only look duplicated. You should be comfortable saying that a screen is done when the interaction works, the text fits, the keyboard path is obvious, and nothing jumps when the window changes size. You should be less comfortable shipping a screen because the screenshot looked fine. The product is software for people who already have too much software. They keep their records in one place, their messages in another, and their memory in a third place that is usually a spreadsheet named final_v7. Nummo sits in the middle and tries to make that less painful. Your job is to make the middle feel calm. Calm is not the same as plain. Calm means a person can tell what happened, what will happen next, and what they are allowed to undo. If a screen needs a paragraph of explanation, the screen is not finished. You will work with product, design, and engineering. Product will describe the outcome. Design will describe the shape. Engineering will describe the constraint. You translate among the three without turning the translation into a fourth document that nobody reads. When those three disagree, you pick the version a user can finish in one sitting. Then you say so out loud, so the disagreement has a place to land. We care about a few things more than taste. Keyboard use has to work. Focus has to be visible. Text has to be readable at the size the window actually is, not the size the mockup assumed. Loading has to look like loading, not like a broken page. Errors have to say what failed and what to try. Empty screens have to say what belongs there. Motion has to be short enough that nobody waits on it. If you remove an animation and the product gets better, remove the animation. You do not need a portfolio of award-winning marketing sites. You need examples of interfaces people use more than once. A settings page you simplified. A table that stayed usable after the columns multiplied. A form that stopped asking for the same fact twice. A component you deleted because two others already did its job. Bring those. If your portfolio is mostly hero sections and gradient orbs, this role will bore you, and the boredom will be mutual. Day to day, you will design in the file and in the code. Sometimes the file comes first. Sometimes the code comes first because the file was wrong about how much text a real account contains. You should be able to open a component, change it, and tell whether the change belongs in the shared library or only on that screen. You should also be able to leave a component alone. Most interface problems are not solved by a new component. They are solved by using the one that already exists and stopping. Here is a fake list of requirements, because job posts always have one: You have built product UI in React and TypeScript. You can implement a layout without a screenshot taped to your monitor. You notice when spacing, type, and alignment drift, and you fix the drift instead of filing a mood. You write components that other people can use without a tour. You care about accessibility as behavior: names, focus, contrast, and keyboard paths. You can work from a rough sketch, a verbal description, or a ticket that says “make it nicer.” You can tell a nicer idea from a worse one in the time it takes to drink a coffee. You are fine deleting your own work when a simpler version shows up. Here is a fake list of things we offer, because job posts always have one of those too: A salary that is a number we would invent if this were real. Health coverage, time off, and the other benefits a real company lists so the posting looks complete. A laptop. You may choose the laptop. The laptop will be slightly worse than the one you wanted. A team that reviews the work, not the number of hours the work took. Permission to make the interface quieter. The interview, if this were an interview, would be a small UI problem. We would give you a clumsy screen and ask you to make it understandable. We would watch what you cut before we watched what you added. We would ask why a control is where it is. “Because the mockup said so” is a weak answer. “Because that is the next thing the person needs” is a strong one. If you want the job, you do not want this job, because this job does not exist. It is 700 words of a design engineering role at Nummo, written so there would be 700 words. The button is still a button. The menu can wait until Monday.

.

.