A collection of thoughts about layout, visual hierarchy, user flow, and interface consistency in digital products.
Every interface I build starts with one question: what does the person want to finish in the next ten seconds? The answer shapes layout, hierarchy and flow more than any style guide does. These notes cover the decisions I repeat across my projects, including Spooniq, Redova and this portfolio.
Layout comes first. I sketch the screen as gray boxes before I pick a color. Boxes show me whether the main action has room, whether related items sit together, and whether the page scans from top to bottom without a detour. I use a spacing scale with a handful of values and stick to it. Equal gaps between unrelated groups look arbitrary, so I make gaps inside a group small and gaps between groups large. Proximity does most of the explaining, and labels do the rest.
Visual hierarchy gets the next pass. On each screen I choose one primary element and make it win: a larger heading, a filled button, a stronger color. Secondary actions get an outline or a text link. If three elements shout at once, the user has to guess, and guessing costs trust. In the portfolio, the maroon hero band marks the top of every page, a heading sits on it, and the content below uses quieter surfaces. A visitor knows where they are before they read a word.
Type does a lot of work. I limit a screen to two or three sizes plus a bold weight, and I keep line length near sixty characters for reading text. Small gray text on a gray background fails people with weaker eyesight and anyone outdoors in sunlight, so I check contrast on every text and background pair. I test colors against the contrast ratios in the WCAG guidelines instead of trusting my eyes on a bright monitor.
User flow matters as much as the look. I write the path as a list of steps and then try to delete steps. In an app that tracks meals, like Spooniq, a user should log a meal in as few taps as possible, because a tedious log gets abandoned. I move optional fields behind a secondary control and fill defaults from the last entry. Each removed tap raises the odds the habit survives past week one.
Feedback closes the loop. A tap needs a visible response within a fraction of a second: a pressed state, a spinner, a toast. Empty states get a sentence and a button that leads somewhere, not a blank area. Errors name the problem and the fix, for example "Check your connection and try again", and never show a raw code. I design these states at the same time as the happy path, since users meet them often.
Consistency lets people reuse what they learned. I define components once, such as buttons, inputs, cards and chips, and reuse them everywhere. A primary button looks and behaves the same on every screen. Icons carry labels where the meaning is not obvious. Navigation stays in the same place from page to page. When I break a pattern, I need a reason I can say out loud.
Responsive behavior starts from the smallest screen. I design for a phone width first, because it forces me to rank content, then widen the layout and let secondary content appear as space allows. Touch targets stay at least 44 pixels so thumbs hit them reliably. I check landscape orientation and large text settings, since those break layouts that look fine on my own device.
Accessibility shapes decisions from the start. Semantic headings give screen readers a map. Focus states stay visible for keyboard users. Motion respects the reduced-motion setting, so animation adds polish for those who want it and gets out of the way for those who do not.
I test with people whenever I can. Five minutes of watching a friend use a prototype shows problems I cannot see after staring at it for hours. I note where they hesitate, because hesitation marks the spot where the interface failed to explain itself. Then I fix that spot, and I watch again.