Web design in the browser: test earlier, design better
A static layout is a useful way to explore an idea. But a website lives in a browser, with real words, changing screen sizes and people making their own choices. We bring the design into that environment early so the difficult questions appear while there is still time to answer them.
Let real content shape the layout
A short placeholder heading is easy to arrange. A real service name, a longer German translation or a description written by the business may need a different solution. We prefer to discover that while the structure is still flexible.
Working with real content shows us where a layout is too rigid. It also helps us identify useful patterns: a heading that can wrap naturally, a card that handles a longer title and a section that stays balanced without a carefully selected paragraph length.
We deliberately try content that is less convenient to arrange. A long company name, a short paragraph and a photograph with its subject near the edge can reveal assumptions hidden by a polished mockup. Solving those cases creates a pattern the team can use with confidence when new material arrives.
Design the spaces between the screens
A desktop mockup and a phone mockup leave a lot of widths unexplored. In the browser, we can resize the page and see where the composition starts to struggle. Sometimes the right response is a different layout, rather than simply making every element smaller.
We look at the order of information as well as the size of things. A layout with elements placed next to each other can become a clear sequence. A wide visual can need a different crop. Navigation should remain usable without relying on a pointer or a large screen.
A useful adjustment has a reason beyond fitting the width. A button may need its own row so its label stays readable. An image may move below the explanation it supports. We choose the order based on what a person needs to understand first and then check the result as a complete page.
Judge interaction by using it
Motion is easier to judge when you can experience it. We can tell whether a transition helps explain the page, whether a hover state feels responsive and whether an effect becomes tiring after the third visit. The same review includes keyboard use and reduced motion.
This does not mean adding animation everywhere. Often the useful choice is to keep an element still. We want movement to support the hierarchy and the interaction, while the page remains clear when that movement is reduced.
We also use the experience without the shortcuts a designer learns during the project. Can a person find the menu, see the focused control and understand what happens after submitting a form? A working version makes those questions visible in a way that a picture cannot.
- Design with real headlines, images and content.
- Check the space between familiar screen sizes.
- Use every control with a keyboard and a touch screen.
- Make the experience clear when motion is reduced.
Keep design and implementation in conversation
An early working version gives everyone something concrete to review. The discussion becomes about the experience a person can use, not just a picture of it. We can adjust the design, the content and the implementation together.
We still sketch and make mockups. We simply do not ask those tools to answer every question. Moving into the browser earlier helps us build a design that survives contact with the real website.
The review becomes more precise when feedback points to an actual moment in the journey. Instead of asking whether a screen feels right, we can discuss a heading that wraps poorly or a step that needs explanation. The team can make a change and immediately see whether it helps.
