Principles & heuristics
The principles I design by. They come from established UX research and from years of designing systems where a missed detail has real consequences.
What this is. When I review a screen, mine or anyone else's, this is what I check it against. Most of it is well-established UX research, and I lean on that rather than inventing rules where the research already has an answer. The rest comes from designing for train dispatchers, launch viewers, and people facing an emergency, where getting it wrong costs more than a bad review.
The short version. A good interface is one people can predict, and one that keeps them in charge. Two habits cover most of what follows. Use the patterns people already know, so their attention goes to the decision in front of them instead of to figuring out the page. And shape the flow around what the person is trying to do, not around how the system happens to be built.
What I'm aiming for
The eight principles
Every screen should answer three questions people ask without realizing it: where am I, what just happened, and how do I get out? The first two come down to keeping the system's status visible, like showing where you are in the navigation and responding right away to every action (Nielsen). Don Norman describes the goal underneath as closing two gaps. One is the distance between what a person wants to do and what the interface makes them do. The other is the distance between what the system is doing and whether the person can tell.
The third question is about control. Every path needs a visible way back, whether that's an undo or an exit from a screen someone opened by mistake. Separately, labels should use the person's words, not the company's (Nielsen's match between the system and the real world).
From my workIn my Trauma app concept, the screen that connects you to a live trauma coach keeps a "Cancel, stay on procedure" option in view, so someone can back out of the call and stay on the step they're on.
Too little: a button that does nothing visible when pressed, labels written in the system's language, a flow you can enter but not undo.
Too much: a confirmation pop-up on every small action, status messages describing what the person can already see.
Part of what makes an action easy or hard is predictable, so I design for it instead of waiting to discover it in testing. Fitts's law says bigger, closer targets are faster to hit, so the main action is large and close to where the person is already working, never a small button far from it. Hick's law says more choices mean slower decisions, so options are grouped and revealed in stages instead of shown all at once. Jakob's law says people spend most of their time on other sites and expect yours to work the same way, so a link looks like a link, the logo goes home, and the navigation sits where people expect it. I only introduce a new pattern where it clearly earns its place.
From my workMy Trauma app concept's home screen leads with one large Emergency button. In a crisis, the most important action should also be the easiest one to hit.
Too little: every button given the same weight so nothing stands out, a fifteen-item menu with no groups, a custom control where a standard one was expected.
Too much: a new navigation idea people have to learn before they can use the site, friction dressed up as delight.
Information architecture is how the parts of something are arranged so the whole makes sense (Abby Covert). I treat that structure as a promise about where things live, and it has to hold across the whole product. Navigation stays consistent on every page and always shows where you are. When a site serves more than one kind of visitor, the structure should do the sorting for them, with labels that say where each path leads and a route to the right place in one or two steps. My test: if someone lands on an inner page from a direct link, can they tell where they are and what's around them?
From my workFor the Hertz EV Hub, I mapped the full site structure before designing any pages, so the new hub fit under the site's Electric Vehicles and Tesla sections without creating orphaned pages or dead ends.
Too little: a flat grid of unrelated links, labels that describe the company instead of guiding the visitor, an inner page with no sense of where it sits.
Too much: categories so deep that people end up navigating a tree instead of reaching anything, a small site split into too many sections.
Two things go wrong in any real flow: a person makes an error, or the system fails. Not everything can be prevented, so I plan for both. First, prevent the errors you can, with constraints that make the wrong action impossible, sensible defaults, and the expected format shown before anyone types. Then keep the cost of the ones that get through low. Make actions reversible where you can, and ask for confirmation only on the ones that can't be undone.
For failures the interface can't prevent, like a dropped connection, plan the fallback ahead of time: keep the person's work, tell them plainly what happened, and never leave them at a dead end. Norman draws a useful line here. A slip is the right goal carried out the wrong way. A mistake is the wrong goal or the wrong plan, often from a wrong picture of how the system works. Constraints and good defaults prevent slips, an interface that works the way people expect prevents mistakes, and recovery catches whatever is left.
From my workIn my rail dispatch work, I redesigned how a safety-critical action gets confirmed: the dispatcher reviews the current state at a glance, then confirms once, deliberately, before the action goes through.
Too little: the wrong action is the easy one, no confirmation on something permanent, an error that throws away what someone typed without explaining why.
Too much: so many warnings and confirmations that the interface gets in the way of ordinary work.
People read a layout before they notice it. Things placed close together read as related, and things that look alike read as the same kind of thing (the Gestalt principles of proximity and similarity). Alignment shows how things connect, and a steady rhythm lets the eye move down the page without having to reorient. Spacing comes from one consistent scale, and line length stays comfortable to read.
Layout also manages how much a person has to hold in their head. Working memory can only hold a few things at once, and everything on the screen competes for it (John Sweller's cognitive load theory), so whatever the moment needs most goes up front, and secondary information waits until someone reaches for it. On a phone the content can reflow, but the reading order has to stay logical and nothing essential should end up out of reach.
From my workFor Blue Origin's New Glenn launch telemetry visualization, which peaked at more than 990,000 concurrent viewers, I tuned the data density so critical flight metrics could be read in under a second.
Too little: related items spread apart and unrelated ones crowded together, a mobile layout that reflows into a confusing order, spacing that falls apart on a phone.
Too much: a grid so elaborate it competes with the content, precision no reader will ever notice.
Accessibility is the foundation everything else stands on, not one item on a checklist. My baseline is WCAG 2.2 AA on every page and component, and I go further where I can. In practice that means text alternatives and captions, color contrast that passes, full keyboard access with a focus highlight you can always see, never hidden behind a sticky header, touch targets big enough to hit, nothing that only works by dragging, no time limits people can't turn off or extend, clear labels, errors that explain how to fix them, and markup that works with a screen reader. Contrast is a requirement the color palette has to meet from the start, not something checked at the end.
From my workRedesigning Blue Origin's public program pages raised accessibility scores 60% over the old site. CraftRole shipped with 82 production-ready components that meet WCAG AA.
Too little: keyboard traps, focus you can't see, contrast left to chance, missing alt text, accessibility saved for a pass that never happens.
Too much: extra ARIA added to elements that were already accessible, an overlay widget used in place of properly built markup.
Any time someone is typing in information to make a decision, the form is where you can lose them. Prevent the error before correcting it: sensible defaults, the expected format shown up front, and limits built into the field rather than rejected after submitting (Nielsen). Check input when it helps, as the person leaves a field, not on every keystroke and not only at the very end. Every field keeps a visible label, and placeholder text is never the label. When something goes wrong, the message sits next to the field, says what happened, and says how to fix it, in plain language.
Too little: placeholder text standing in for labels, only a list of errors at the top after submitting, with nothing next to the fields, formats you only learn by getting them wrong.
Too much: errors that fire on every keystroke, a form that interrupts to congratulate you.
Motion should be felt more than watched. It earns a place only when it communicates something, like a change in state or where something came from or went. Speed matters more than it looks: when a response arrives within about 400 milliseconds, people feel the system is keeping pace with them (the Doherty threshold). Past about a second, they need to see that something is happening, or they start to wonder whether it worked (Jakob Nielsen). Showing right away that an action registered matters more than shaving time off the full response. Every animation respects the reduced-motion setting, and nothing important is communicated through motion alone.
Too little: an action with no feedback, a wait with no sign that anything is happening, animation that ignores the reduced-motion setting.
Too much: decorative animation on load and scroll, transitions so slow that people end up waiting on the motion itself.
What I don't compromise on
I design every page and component to meet WCAG 2.2 AA. Accessibility is part of the design, not a later phase.
People bring habits from every other product they use. I meet those habits and save new ideas for where they clearly help, never for core navigation or input.
Every page has one main thing to do, and the next step is obvious. The page doesn't compete with itself.
No tricks to keep people subscribed, no guilt-trip buttons, no disguised ads, no fake urgency. If a product is worth using, being clear about it is enough to make the case.
A product has to work for whoever shows up, without assuming they're already an expert. Kat Holmes describes exclusion as a mismatch between a person and a design, not a flaw in the person, so the fix belongs in the design, and it often makes the product better for everyone. And anywhere a system acts on someone's behalf, there has to be a clear way to stop it and take over. A product where the person becomes optional was built wrong.
If you're looking at my work, this is the bar I hold it to. You'll find these principles at work across the case studies.
Frank Mellana · Updated September 2026