# Ionut Maxim > Designer și mentor concentrat pe claritate, judecată și gândire în jurul produselor digitale. Ajut echipe mici și medii să diagnosticheze ce este de fapt stricat și să decidă ce urmează. Generated: 2026-10-08T18:10:58.664Z # Writing --- ## Slow clarity Source: https://imcom.vercel.app/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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 --- ## Rețeaua care se așază Source: https://imcom.vercel.app/ro/lab/settling-lattice TLDR: Un studiu viu despre ordine și perturbare: o rețea de puncte în repaus. Împinge-o cu cursorul și se umflă; dă click și un val o străbate — apoi se așază la loc în grilă. Plimbă cursorul peste câmpul de mai sus. Un val blând te urmează, ridicând punctele de dedesubt. Dă click și un val se propagă spre exterior prin grilă. Apoi — lăsată în pace — totul se așază la loc în ordine. Așezarea aceea e tot rostul. ## De ce aceasta Cea mai mare parte din munca la care țin e despre sisteme care absorb o perturbare și revin la coerență — un produs, o echipă, un brief. Poți să împingi într-unul sănătos și se îndoaie, se reorganizează și își regăsește nivelul. Unul fragil păstrează urma loviturii. Aici e aceeași idee, fără nimic altceva atașat: o structură regulată, o forță și o revenire. E intenționat liniștită. Momentul interesant nu e impactul — sunt cele câteva secunde de după, când ordinea se reafirmă. ## Cum funcționează O grilă de puncte stă pe un plan, văzută ușor înclinat, ca să citească drept spațiu, nu drept tapet. Cursorul se proiectează pe plan și ridică o „groapă" gaussiană sub el; un click emite un inel care se extinde, a cărui amplitudine scade în timp. Înălțimea controlează atât dimensiunea, cât și o virare caldă spre accent, așa că o perturbare strălucește scurt, apoi se răcește pe măsură ce se aplatizează. E un singur buffer de puncte și câteva linii de matematică în shader — destul de ieftin ca să ruleze fluid, destul de reținut ca să-l lași pe o pagină fără să țipe. ## Întrebări deschise - Ar trebui ca un al doilea cursor (sau o atingere) să interfereze cu primul, așa cum ar face două perturbări reale? - Cum se simte dacă revenirea e ușor *imperfectă* — o urmă slabă a loviturii rămasă în urmă? - Există o versiune a acestui lucru care își are locul într-un produs, nu doar într-un studiu — o stare de încărcare, senzația unui sistem care respiră? --- ## Câmp elastic Source: https://imcom.vercel.app/ro/lab/spring-field TLDR: Un câmp de puncte pe o grilă. Cursorul le desparte — fiecare sare în afară cu cât ești mai aproape — și în clipa în care pleci, sar înapoi acasă. Mișcă cursorul printre punctele de mai sus. Fiecare sare în afară proporțional cu cât de aproape ești, încălzindu-se pe măsură ce se mișcă; pleacă, și arcurile trag tot câmpul înapoi în grila lui. ## De ce aceasta Sistemele bune sunt elastice, nu rigide. Împinge în ele și cedează — local, proporțional — apoi își recapătă forma fără să păstreze urma loviturii. Asta e valabil pentru un roadmap rezilient, o echipă sănătoasă, o interfață bine făcută. Lucrurile rigide crapă; cele fragile rămân îndoite. Aici e elasticitatea fără nimic altceva atașat. ## Cum funcționează [Framer Motion](https://motion.dev) și fizica lui de arcuri — o idee diferită de un timeline GSAP. Nu există nicio animație pe keyframe-uri aici: fiecare punct își derivă un offset *țintă* din poziția vie a cursorului (o motion value), iar un arc urmărește continuu acea țintă. Scoate input-ul și ținta revine la zero, așa că arcul aduce totul acasă de unul singur. --- ## Cascadă Source: https://imcom.vercel.app/ro/lab/cascade TLDR: O grilă în repaus. Dă click și un val se propagă din acea celulă — fiecare vecină pulsează cu o întârziere dată de distanță, apoi se așază. Dă click pe orice celulă de mai sus (sau plimbă-te peste ele) și un val se propagă spre exterior — fiecare celulă pulsează cu o întârziere proporțională cu distanța față de locul atins, apoi câmpul se așază la loc. ## De ce aceasta O singură decizie nu e niciodată locală. Călătorește — printr-un roadmap, o echipă, un layout — iar întrebarea e cât de departe ajunge și cât de curat. Sistemele sănătoase propagă o schimbare ca un singur val coerent; cele fragile o împrăștie în zgomot. Aici e acea propagare, izolată și făcută vizibilă. ## Cum funcționează [Web Animations API](https://developer.mozilla.org/docs/Web/API/Web_Animations_API) al browserului — `element.animate()` — fără nicio bibliotecă. La fiecare declanșare, fiecare celulă primește același keyframe scurt (un puls de scalare + accent), dar un `delay` diferit, calculat din distanța ei în grilă față de celula de origine. Platforma programează și rulează toată cascada în afara firului principal. --- ## Subdiviziune Source: https://imcom.vercel.app/ro/lab/subdivision TLDR: Un dreptunghi, divizat. Dă click pe orice celulă ca să o împarți pe latura mai lungă — o compoziție care se asamblează singură, o decizie pe rând. Dă click pe orice celulă de mai sus și se împarte pe latura mai lungă, într-un raport descentrat. Perechea nouă apare estompat, cu o margine scurtă în accent, apoi se răcește la o linie subțire. Continuă și o compoziție se construiește singură. ## De ce aceasta Layout-ul nu e un singur gest grandios — e o secvență de tăieturi mici, fiecare pe care ar trebui să o poți apăra într-o propoziție. „Se împarte aici pentru că…" Constrângerea interesantă e să știi când să te oprești: fiecare tăietură cumpără claritate până când, la un moment dat, următoarea cumpără doar dezordine. ## Cum funcționează Dreptunghiuri [SVG](https://developer.mozilla.org/docs/Web/SVG) simple, conduse de puțin state în React — fără canvas, fără bibliotecă de animație. Fiecare împărțire alege axa mai lungă și un raport descentrat derivat determinist din poziția celulei, așa că rezultatul pare compus, nu aleatoriu; o tranziție CSS estompează celulele noi și le răcește marginea accent. Celulele nu mai pot fi împărțite odată ce ar coborî sub o dimensiune minimă. --- ## Derivă Source: https://imcom.vercel.app/ro/lab/drift TLDR: Sute de firicele urmează un curent invizibil, fiecare lăsând o urmă care se stinge, așa că fluxul se desenează singur. Cursorul le atrage în trecere. Fiecare firicel de mai sus urmează un câmp de curgere pe care nu îl poți vedea direct — doar urmele îl fac vizibil. Mișcă cursorul și firicelele din apropiere se înclină spre el, se încălzesc spre accent, apoi se reîntorc în curent. ## De ce aceasta Rareori apuci să vezi comportamentul unui sistem direct. Îi vezi *urmele* — unde s-a dus atenția, ce a fost revizitat constant, ce cărări s-au tocit. Să citești bine acele urme e mare parte din diagnostic. Aici e ideea aceea fără nimic atașat: o regulă invizibilă, făcută lizibilă doar prin semnele pe care le lasă. ## Cum funcționează [Canvas 2D](https://developer.mozilla.org/docs/Web/API/Canvas_API) simplu — fără bibliotecă. Câteva sute de particule citesc fiecare un mic câmp de value-noise ca să-și aleagă direcția, fac un pas și desenează un segment scurt; toată pânza e spălată cu un strop din culoarea hârtiei la fiecare cadru, așa că semnele vechi se sting și rămâne aprins doar fluxul viu. Cursorul adaugă o atracție locală care scade cu distanța. --- ## Câmp de curgere Source: https://imcom.vercel.app/ro/lab/flow-field TLDR: Un câmp de zgomot care plutește, desenat ca linii de contur. Mișcă cursorul și un vârtej lent îndoaie liniile în jurul lui, apoi se relaxează la loc. Liniile de mai sus sunt contururile unui câmp de zgomot care plutește încet. Mișcă cursorul prin ele și un vârtej blând îndoaie topografia în jurul lui; pleacă, și se relaxează înapoi la plutirea ei liniștită. ## De ce aceasta Multe situații par, la prima vedere, zgomot nediferențiat — un produs care „nu e în regulă", o echipă care „nu se leagă". Munca e să găsești liniile de contur: structura care a fost mereu acolo, odată ce o desenezi. Vârtejul e aceeași idee — o forță mică face câmpul de dedesubt lizibil pentru o clipă. ## Cum funcționează Randat cu [OGL](https://github.com/oframe/ogl), o micro-bibliotecă WebGL de circa 8KB — un singur triunghi pe tot ecranul și un fragment shader. Shader-ul e zgomot fractal cu domeniu deformat (zgomot care conduce coordonatele altui zgomot) transformat în benzi de contur; cursorul rotește domeniul de eșantionare în jurul lui, cu o atenuare după distanță. Fără scene graph, fără mesh-uri — doar matematică pe fiecare pixel. --- ## Secvență Source: https://imcom.vercel.app/ro/lab/sequence TLDR: Un singur timeline orchestrează un șir de bare într-un val care se deplasează. Trage peste el ca să derulezi timpul cu mâna; dă-i drumul și pornește singur. Barele de mai sus sunt controlate de un singur timeline. Fiecare se ridică, se încălzește și se așază cu o fracțiune după vecina ei — un val pe care îl poți privi rulând sau pe care îl poți apuca și derula înainte și înapoi trăgând peste el. ## De ce aceasta Mare parte din ce face o muncă să pară chibzuită ține de *secvență* — ordinea în care lucrurile apar, se rezolvă și fac loc următorului. Un proces bun are aceeași calitate ca un timeline bun: îl poți pune pe pauză, îl poți derula și poți explica de ce fiecare moment cade exact acolo. ## Cum funcționează [GSAP](https://gsap.com) construiește un timeline principal; fiecare bară primește o pereche de tween-uri decalate (urcare, apoi așezare) plasate cu un offset de-a lungul șirului, iar un cap de redare e legat de același ceas. Tragerea pune redarea pe pauză și mapează poziția x a cursorului pe progresul timeline-ului — așa că toată coregrafia devine ceva ce ții în mână. --- ## Interface studies Source: https://imcom.vercel.app/ro/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/ro/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/ro/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/ro/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/ro/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/ro/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?