# Ionut Maxim > Designer and mentor focused on clarity, judgment, and digital product thinking. Helps small-to-mid product teams diagnose what is actually broken and decide what to do next. Generated: 2026-10-08T19:32:32.087Z # Writing --- ## Slow clarity Source: https://imcom.vercel.app/en/writing/slow-clarity TLDR: Why some problems get worse the faster you try to solve them, and what it looks like to design at a pace that actually fits the work. **why the best decisions take time** ## Speed as a default Most product teams treat speed as a default virtue. Ship faster, decide faster, iterate faster. There is a real version of this that is healthy. There is also a version that quietly damages the work. The damaging version shows up when the team starts solving the wrong problem quickly, or when the speed of decision making outruns the speed of understanding. ## What slow clarity looks like Slow clarity is not slow execution. It is fast execution on the right problem, after taking the time to understand what the right problem is. It usually looks like a few extra days at the beginning of a project where you resist the urge to start drawing screens. You write the problem down. You argue with it. You let it sit overnight. When the problem is clear, the design work compresses. Not because anyone is going faster, but because nothing is being thrown away. ## When to refuse speed The hardest part of slow clarity is the social cost of refusing to move on the first day. Teams reward visible motion. A designer who is "still thinking" looks like a designer who is stuck. A designer who is filling a Figma file looks productive. Most of the time, the visible thinker is doing the more useful work. Defending that requires a kind of professional self-trust that takes years to build, and that mentorship can help compress. --- ## Mentorship as discipline Source: https://imcom.vercel.app/en/writing/mentorship-as-discipline TLDR: Mentorship gets romanticised. The actual practice is closer to a craft: deliberate, structured, and oriented around judgment, not motivation. **Mentorship as discipline, not vibes** ## The vibes version The most common version of mentorship online is closer to motivational coaching than to craft. A senior person tells a junior person to believe in themselves, charges for the calendar slot, and posts a screenshot. There is nothing wrong with encouragement. There is something wrong with calling that mentorship. ## What discipline looks like Discipline-shaped mentorship is built around a few things: - A clear scope: what we are working on and what we are not. - A diagnostic: where you actually are, not where you want to be. - A path: the next two or three moves, ordered. - A checkpoint: when do we look again, and what counts as progress. None of that requires charisma. It requires honesty, patience, and a willingness to say uncomfortable things kindly. ## Why this matters When mentorship is treated as discipline, the people on the receiving end get something they can actually use. They leave with sharper judgment, not just a warmer feeling. That is the version I am interested in. It is harder to market and it does not photograph well. It also tends to be the only kind that compounds. --- ## Judgment over process Source: https://imcom.vercel.app/en/writing/judgment-over-process TLDR: Frameworks are scaffolding. At some point you have to take the scaffolding down and just decide. **when frameworks stop helping** ## Frameworks as scaffolding Frameworks are useful when you do not yet have judgment. They give you a sequence to follow while you are building the muscle to know which step matters. They become a problem when they outlast the moment they were useful in. Teams keep running the framework long after the situation has changed. ## How to know it is time There are usually a few signs that a framework has become a crutch: - The output of each step is filled in but no one is making real decisions. - People reach for the framework when they are uncomfortable, not when they are stuck. - The same conclusion keeps coming back from the framework, no matter the input. When any of these show up, the framework is doing emotional work, not analytical work. ## What replaces it What replaces a framework is not the absence of structure. It is judgment plus a smaller, lighter structure that you can defend. A good way to test that you are ready is whether you can write the decision down in a paragraph without reaching for a template. --- ## Small bets on yourself Source: https://imcom.vercel.app/en/writing/small-bets-on-yourself TLDR: Career change rarely arrives in a single leap. It is much more often the cumulative result of a long series of small, deliberate bets. **Small bets on yourself, over and over** ## The big move myth The career story most often told is the dramatic one. The big quit, the side project that exploded, the conference talk that changed everything. The careers I have watched up close almost never look like that. They look like a series of small bets, most of which did not pay off, a few of which compounded. ## What a small bet looks like A small bet is usually: - Cheap enough that you can afford to lose it. - Specific enough that you can tell whether it worked. - Recurring enough that you place several over time, not just one. Writing in public, taking on a small client outside your usual scope, learning a new tool, mentoring one person — all of those are small bets. ## Why this is the realistic path Small bets are not glamorous, but they are honest. They survive bad years, they do not require luck, and the compounding is real. The job is to keep placing them, calmly, when no one is watching. --- ## Designing for trust Source: https://imcom.vercel.app/en/writing/designing-for-trust TLDR: Usability gets you a working product. Trust is what makes someone come back, recommend it, or forgive a mistake. **Designing for trust, not just usability** ## The two layers Most product design education stops at usability. Can the user complete the task, in how many steps, with how many errors. That is necessary but not sufficient. Trust is the layer above. It is the cumulative feeling a user builds about whether the product is on their side. ## Where trust is built or lost Trust is built in the small moments most usability frameworks ignore: - How a confirmation message is worded after a sensitive action. - Whether a pricing page hides anything. - Whether the empty state respects the user as an adult. - Whether an error message takes responsibility or blames the user. Each of those is a tiny act of being on the user’s side, or not. ## Why trust is the real moat Features get copied. Usability gets matched. Trust accumulates over years and gets transferred by word of mouth. A team that designs for trust ends up with users who will tolerate bugs, recommend the product, and stay through the ugly version of a redesign. That is a real moat. --- ## Designing for the quiet user Source: https://imcom.vercel.app/en/writing/designing-for-the-quiet-user TLDR: Most products are designed for the loudest user. The quiet majority deserves better. ## Notes Older post, archived from earlier writing. --- ## Designing without ego Source: https://imcom.vercel.app/en/writing/designing-without-ego TLDR: How to take feedback, kill darlings, and stay attached to the problem instead of the solution. ## Notes Older post, archived from earlier writing. --- ## Good enough is good enough Source: https://imcom.vercel.app/en/writing/good-enough-is-good-enough TLDR: A defence of shipping at 80%, and an honest look at the cost of waiting for perfect. ## Notes Older post, archived from earlier writing. --- ## On being a junior Source: https://imcom.vercel.app/en/writing/on-being-a-junior TLDR: What I wish someone had told me in my first three years as a designer. ## Notes Older post, archived from earlier writing. --- ## The one question that changes everything Source: https://imcom.vercel.app/en/writing/one-question-that-changes-everything TLDR: The single question I keep coming back to when a project stalls, a team disagrees, or a brief feels off. ## Notes Older post, archived from earlier writing. --- ## Your product is not perfect Source: https://imcom.vercel.app/en/writing/product-is-not-perfect TLDR: Why imperfect, useful products beat polished and irrelevant ones, and what to ship even when you would rather wait. ## Notes Older post, archived from earlier writing. Reach out if you would like the full text. --- ## Simplicity is a discipline Source: https://imcom.vercel.app/en/writing/simplicity-is-a-discipline TLDR: Simplicity is not the starting point. It is the result of choosing what not to include, over and over. ## Notes Older post, archived from earlier writing. --- ## The cost of clarity Source: https://imcom.vercel.app/en/writing/the-cost-of-clarity TLDR: Clarity is not free. It costs time, ego, and the comfort of staying ambiguous on purpose. ## Notes Older post, archived from earlier writing. --- ## Why I write Source: https://imcom.vercel.app/en/writing/why-i-write TLDR: Writing as a way to think, not just to share. Why I keep doing it even when nobody reads. ## Notes Older post, archived from earlier writing. --- ## Craft vs output Source: https://imcom.vercel.app/en/writing/craft-vs-output TLDR: When output stops being a proxy for craft, and how to tell which one you are actually optimising for. ## Notes Older blog post, archived. --- ## The design review that actually works Source: https://imcom.vercel.app/en/writing/the-design-review-that-actually-works TLDR: A practical structure for design reviews that produce decisions instead of opinions. ## Notes Older blog post, archived. --- ## Beyond the portfolio Source: https://imcom.vercel.app/en/writing/beyond-the-portfolio TLDR: The portfolio gets you in the room. What you say in the room is what gets you the job. ## Notes Older blog post, archived. --- ## On being wrong in public Source: https://imcom.vercel.app/en/writing/on-being-wrong-in-public TLDR: Why being publicly wrong is a faster path to being right than waiting to be sure. ## Notes Older blog post, archived. --- ## Small teams, big decisions Source: https://imcom.vercel.app/en/writing/small-teams-big-decisions TLDR: The advantages of small teams when the decisions are large, and the trap of confusing size with seriousness. ## Notes Older blog post, archived. --- ## Designing with strangers Source: https://imcom.vercel.app/en/writing/designing-with-strangers TLDR: How to do good design work with people you have never met, in industries you do not know. ## Notes Older blog post, archived. --- ## The quiet skill of saying no Source: https://imcom.vercel.app/en/writing/the-quiet-skill-of-saying-no TLDR: A defence of polite, well-reasoned no. The most senior skill nobody teaches you. ## Notes Older blog post, archived. --- ## When to redesign Source: https://imcom.vercel.app/en/writing/when-to-redesign TLDR: Most redesigns are emotional decisions dressed as strategic ones. A short test to tell the difference. ## Notes Older blog post, archived. --- ## Process is a prosthetic Source: https://imcom.vercel.app/en/writing/process-is-a-prosthetic TLDR: Process is what you reach for when judgment is not yet there. When judgment is there, process should fade. ## Notes Older blog post, archived. --- ## What clients actually buy Source: https://imcom.vercel.app/en/writing/what-clients-actually-buy TLDR: Clients do not buy deliverables. They buy a future feeling about a decision. Design around that. ## Notes Older blog post, archived. --- ## Mentorship and the second brain Source: https://imcom.vercel.app/en/writing/mentorship-and-the-second-brain TLDR: The role of a mentor is partly to be a temporary second brain. What that means in practice. ## Notes Older blog post, archived. --- ## On leaving a company Source: https://imcom.vercel.app/en/writing/on-leaving-a-company TLDR: A short note on how to leave well, and why it matters more than how you arrived. ## Notes Older blog post, archived. --- ## Design as translation Source: https://imcom.vercel.app/en/writing/design-as-translation TLDR: Most product design is translation work: turning ambiguous intent into something a team can build, defend, and learn from. ## Notes Older blog post, archived. # Lab --- ## The settling lattice Source: https://imcom.vercel.app/en/lab/settling-lattice TLDR: A live study in order and disturbance: a lattice of points at rest. Push it with the cursor and it swells; click and a ripple runs through — then it settles back into the grid. Move your cursor across the field above. A soft swell follows you, lifting the points beneath it. Click, and a ripple runs outward through the grid. Then — left alone — everything settles back into order. That settling is the whole point. ## Why this one Most of the work I care about is about systems that absorb a disturbance and come back to coherence — a product, a team, a brief. You can push on a healthy one and it flexes, reorganises, and finds its level again. A brittle one keeps the dent. This is the same idea with nothing else attached: a regular structure, a force, and a return. It is deliberately quiet. The interesting moment is not the splash — it is the few seconds afterwards, when the order reasserts itself. ## How it works A grid of points sits on a plane, seen at a slight tilt so it reads as space rather than wallpaper. The cursor projects onto that plane and raises a Gaussian "well" beneath it; a click emits an expanding ring whose amplitude decays over time. Height drives both size and a warm shift toward the accent, so a disturbance briefly glows and then cools as it flattens. It is one buffer of points and a handful of lines of shader maths — cheap enough to run smoothly, restrained enough to leave on a page without it shouting. ## Open questions - Should a second cursor (or touch) interfere with the first, the way two real disturbances would? - What does it feel like if the return is slightly *imperfect* — a faint memory of the dent left behind? - Is there a version of this that belongs in a product, not just a study — a loading state, a sense of a system breathing? --- ## Spring field Source: https://imcom.vercel.app/en/lab/spring-field TLDR: A field of dots on a grid. The cursor parts them — each springs outward by how close you are — and the moment you leave, they spring home. Move your cursor across the dots above. Each one springs away in proportion to how near you are, warming as it moves; leave, and the springs pull the whole field back into its grid. ## Why this one Good systems are elastic, not rigid. Push on them and they yield — locally, proportionally — and then recover their shape without keeping the dent. That is true of a resilient roadmap, a healthy team, a well-made interface. Rigid things crack; brittle things stay bent. This is elasticity with nothing else attached. ## How it works [Framer Motion](https://motion.dev) and its spring physics — a different idea from a GSAP timeline. There is no keyframed animation here at all: each dot derives a *target* offset from the live cursor position (a motion value), and a spring continuously chases that target. Remove the input and the target returns to zero, so the spring carries everything home on its own. --- ## Cascade Source: https://imcom.vercel.app/en/lab/cascade TLDR: A grid at rest. Click and a wave ripples out from that cell — each neighbour pulses on a delay set by its distance, then settles. Click any cell above (or sweep across them) and a wave ripples outward — each cell pulses with a delay proportional to how far it sits from where you touched, then the field settles back to rest. ## Why this one A single decision is never local. It travels — through a roadmap, a team, a layout — and the question is how far it reaches and how cleanly. Healthy systems propagate a change as one coherent wave; brittle ones scatter it into noise. This is that propagation, isolated and made watchable. ## How it works The browser's own [Web Animations API](https://developer.mozilla.org/docs/Web/API/Web_Animations_API) — `element.animate()` — with no library at all. On each trigger, every cell gets the same short keyframe (a scale + accent pulse) but a different `delay`, computed from its grid-distance to the origin cell. The platform schedules and runs the whole cascade off the main thread. --- ## Subdivision Source: https://imcom.vercel.app/en/lab/subdivision TLDR: A rectangle, divided. Click any cell to split it along its longer edge — a composition assembling itself one decision at a time. Click any cell above and it splits along its longer edge, at an off-centre ratio. The new pair fades in with a brief accent edge, then cools to a hairline. Keep going and a composition builds itself. ## Why this one Layout is not a single grand gesture — it is a sequence of small cuts, each of which you should be able to defend in a sentence. "This splits here because…" The interesting constraint is knowing when to stop: every cut buys clarity until, at some point, the next one only buys clutter. ## How it works Plain [SVG](https://developer.mozilla.org/docs/Web/SVG) rectangles driven by a little React state — no canvas, no animation library. Each split picks the longer axis and an off-centre ratio derived deterministically from the cell's position, so the result feels composed rather than random; a CSS transition fades new cells in and cools their accent edge. Cells stop being splittable once they'd fall below a minimum size. --- ## Drift Source: https://imcom.vercel.app/en/lab/drift TLDR: Hundreds of motes follow an invisible current, each leaving a fading trail, so the flow slowly draws itself. The cursor pulls them in passing. Each speck above is following a flow field you cannot see directly — only the trails make it visible. Move your cursor and the nearby motes lean toward it, warm to the accent, then rejoin the current. ## Why this one You rarely get to see a system's behaviour head-on. You see its *traces* — where attention went, what kept getting revisited, which paths wore smooth. Reading those traces well is most of diagnosis. This is that idea with nothing attached: an invisible rule, made legible only by the marks it leaves. ## How it works Plain [Canvas 2D](https://developer.mozilla.org/docs/Web/API/Canvas_API) — no library. A few hundred particles each read a small value-noise field to choose a heading, step forward, and draw a short segment; the whole canvas is washed with a sliver of the paper colour every frame, so old marks fade and only the living flow stays bright. The cursor adds a local attraction that falls off with distance. --- ## Flow field Source: https://imcom.vercel.app/en/lab/flow-field TLDR: A drifting noise field drawn as contour lines. Move the cursor and a slow swirl bends the lines around it, then they relax back. The lines above are contours of a noise field, drifting slowly. Move your cursor through them and a soft swirl bends the topography around it; leave, and it relaxes back to its quiet drift. ## Why this one A lot of situations look, at first glance, like undifferentiated noise — a product that "feels off", a team that "isn't clicking". The work is finding the contour lines: the structure that was always there, once you draw it. The swirl is the same idea — a small force makes the underlying field legible for a moment. ## How it works Rendered with [OGL](https://github.com/oframe/ogl), a roughly 8KB WebGL micro-library — one full-screen triangle and a fragment shader. The shader is domain-warped fractal noise (noise driving the coordinates of more noise) turned into contour bands; the cursor rotates the sampling domain around itself with a distance falloff. No scene graph, no meshes — just maths per pixel. --- ## Sequence Source: https://imcom.vercel.app/en/lab/sequence TLDR: One timeline orchestrates a row of bars into a travelling wave. Drag across it to scrub time by hand; let go and it plays on. The bars above are driven by a single timeline. Each one rises, warms, and settles a beat after its neighbour — a wave you can watch play, or grab and scrub backwards and forwards by dragging across it. ## Why this one Most of what makes work feel considered is *sequence* — the order in which things arrive, resolve, and give way to the next thing. A good process has the same quality as a good timeline: you can pause it, scrub it, and explain why each moment lands where it does. ## How it works [GSAP](https://gsap.com) builds one master timeline; each bar gets a staggered pair of tweens (rise, then settle) placed at an offset down the line, and a playhead is tied to the same clock. Dragging pauses playback and maps the cursor's x-position onto the timeline's progress — so the whole choreography becomes a thing you hold in your hand. --- ## Interface studies Source: https://imcom.vercel.app/en/lab/interface-studies TLDR: Quiet layout systems, restraint as a feature, and the choices that shape a screen before any pixel is drawn. An ongoing notebook of layout sketches, type pairings, and quiet interface details. Most of them never become products. They exist to keep the muscle of looking and noticing alive. I treat these as exercises: what happens if I remove a column, change the rhythm, push the type one size smaller. The interesting answers tend to be the boring-looking ones. ## What I am looking for Most product screens are noisier than they need to be. I am looking for the version that earns each element, where every line of type, divider, and label is doing real work. When I cannot defend a thing on the screen out loud in one short sentence, that is usually a sign it does not belong yet. ## How it informs client work The studies are where I rehearse decisions before they get expensive. By the time a problem arrives in a real product, I have usually already sketched a version of it here. It also keeps me honest. It is much harder to defend a busy layout in client work if I cannot make a quiet one work in a study. ## Plates
## Open questions - When does restraint stop being restraint and become emptiness? - How do you keep a quiet layout from feeling cold? - Which conventions are worth keeping, and which are habit dressed as standard? --- ## AI prompting patterns Source: https://imcom.vercel.app/en/lab/ai-prompting-patterns TLDR: Notes on prompts as design objects: structure, tone, voice, and the difference between an answer and a useful answer. Prompts are interfaces. They have hierarchy, voice, defaults, and edge cases. I have been treating them with the same care I would treat a form, a settings page, or a piece of UX copy. This track is a collection of patterns that keep showing up: how to scope a task, how to set a tone, how to give the model just enough context without drowning it. ## Prompts as products A prompt is a product surface. Someone is going to copy it, edit it, paste it into a context window, and live with the answer for a while. That means the same questions apply: who is this for, what does success look like, what is the failure mode, what gets cut. ## Voice and defaults I am especially interested in how the framing of a prompt sets tone. A small change in voice up front tends to do more for output quality than long lists of rules at the bottom. Defaults matter too. If I want short answers, I have to say so early, and ideally show what short means. ## Plates
## Open questions - What is a prompt's equivalent of an empty state? - How do you version prompts the way you version components? - When should a prompt say less, not more? --- ## Motion experiments Source: https://imcom.vercel.app/en/lab/motion-experiments TLDR: Micro interactions, easing curves, and the moments where motion makes an interface feel honest instead of decorative. Motion is one of the easiest things to overdo and one of the hardest things to do well. This track is about the small moments: a hover, a state change, a transition that confirms instead of decorates. I keep coming back to easing curves. They are the punctuation of an interface. ## Motion that confirms The best micro motion answers a question the user did not even realise they were asking: did this register, where am I now, is something happening. When motion is doing that job, you barely notice it. When it is decorative, you notice it once and resent it the second time. ## Curves as character Two products can use the same animation duration and feel completely different because of the curve. A linear ease feels industrial. A soft cubic ease feels considered. I am interested in how curves can carry brand without anyone ever explicitly noticing them. ## Plates
## Open questions - When does motion stop being feedback and start being friction? - How do you brief easing in a written spec? - Where does motion belong on a static page like this one? --- ## Typography studies Source: https://imcom.vercel.app/en/lab/typography-studies TLDR: Type as voice, rhythm, and tone. Specimens, pairings, and the small calibration that changes how a sentence reads. Type is voice. Two products can say the same words and read completely differently because of how those words are set. This track collects pairings, specimen sheets, and small rhythm studies. Most of them sit unused, which is fine. The point is to keep training the eye. ## Pairing as decision I try to make type pairing a decision, not a habit. That means starting from voice: who is talking, in what register, to whom. Once that is clear, the type often picks itself. Most pairing problems are actually unresolved voice problems. ## Rhythm and reading Line length, leading, and size are where rhythm lives. Most reading discomfort I see in products is fixable in those three values, before any font swap. I run the same paragraph through three rhythm settings and see which one disappears. The one that disappears is usually right. ## Plates
## Open questions - How do you brief type voice without falling back to adjectives? - When is a custom typeface worth it for a product team? - What does good system typography look like at scale? --- ## Early product ideas Source: https://imcom.vercel.app/en/lab/early-product-ideas TLDR: Half formed product sketches and what-ifs. The point is not to ship them but to understand why most of them should not exist. A folder of product ideas in their messy, early form. Most of them will not survive their own first audit, which is the point. The exercise is to take an idea seriously enough to write it down, then ask the boring questions: who is this for, what does it replace, what does it cost, why now. ## Sketching to disqualify I treat early sketches as a way to kill ideas faster, not slower. The faster I can find the breaking point, the cheaper the lesson. An idea that survives a few rounds of honest questioning is rare. Those are the ones worth showing to anyone else. ## Why most ideas should not exist Most product ideas die for the same handful of reasons: no real user, no real wedge, no honest distribution story, no compounding return. Writing those reasons down explicitly turns a vague gut feeling into something you can argue with. ## Plates
## Open questions - How do you keep early ideas honest without killing them too fast? - What is the cheapest possible test of a product hypothesis? - When is a sketch ready to leave the notebook? --- ## Brand studies Source: https://imcom.vercel.app/en/lab/brand-studies TLDR: Personal exercises in brand voice, mark making, and the small visual decisions that make a system feel intentional. Fictional brand briefs that I use to practice voice, mark making, and system thinking outside of client constraints. Nothing here is meant to live in the world. They exist to keep the discipline of building a coherent system, from a single mark out to a full applied system, sharp. ## Voice before mark I try to do voice work before any visual work. The mark, the type, and the colour are downstream decisions if voice is clear. Most brand systems that feel inconsistent are not actually visually broken. They are voice problems that visual choices cannot patch. ## System over surface Surface is what most people notice. System is what makes a brand survive contact with a real team over years. These studies are mostly about that quieter layer: how a system holds when applied at different sizes, languages, and contexts. ## Plates
## Open questions - How do you brief voice without copying someone else's adjectives? - When does a system stop helping and start constraining? - What makes a mark feel inevitable versus arbitrary?