How I do web design Published: 24 December 2025 Updated: 24 December 2025 Seven years ago, I started writing down the things that actually helped me as a designer. Not theories: practical lessons. I updated the list occasionally, then forgot about it altogether. I found it again today and expanded it with what some of the things I’ve learned since. It’s all over the place ranging from things I’ve learned in school till what I learned last week. Maybe there’s something useful in there for you. Work on a big idea before details. Your work can only be as good as the organization you’re part of. Start with pen and paper sketches. Every task is part of a process or a project. Processes (repeatable projects, f.e. creating social media images) must be formalized. Carefully pick a design method for each project. Whatever you create, align with the stakeholders in your organization on goals, requirements and some rough visuals before spending serious time on it. Balance responding to change with sticking to processes and methods. Or, more generally, balance short-time goals with long-term goals. Success requires both, but the wrong balance is the cause of all failure. No person or method can prioritize projects with guaranteed ideal outcomes. In the end it comes down to gut feeling and personal preferences. Also, any time you spend on planning, you can’t spend executing your plan. Create something before deciding on a solution. If people attempt to start projects with a solution, define the problem and scope first. Agree on working on the problem without committing to the solution. The magic of a team working together beats process, but a good process can definitely help create that team magic. Spend design time on things that are unique for your product/service/organization and important to your user base. Use common patterns for everything else. You don’t want to spend the rest of your life designing newsletter signup forms. Test before building, prototype before testing, outline your test report before prototyping. Prototypes are about behavior, not about looks. They must be interactive and don’t have to adhere to style guides. Prototypes for user testing must be as close to the real thing as possible. Detail design can make the difference between a feature getting noticed and being ignored. Prototypes should be single-purpose, so you can discard them after testing. You don’t want to maintain a complete shadow product only the design team can truely appreciate. Don’t be a tools purist; it doesn’t matter if design artefacts are nicely in one file or spread over many tools. Take risks being transparent to your organization. Give everyone Figma access. Do your documentation and presentations using the tools everyone is using. The more you include non-designers in your work, the less time you have to spend on big, risky presentations. PowerPoint sucks, but if that’s your org’s communication medium, you have to use it to be noticed. A lot about design is about evoking visceral responses. Expect stakeholders to react emotionally to your work. Don’t get defensive or discouraged if they’re upset about what they consider the ugly shit you present them. Instead, use the opportunity to find out how the design can be improved. All aspects of a design must be successful for a design to work: interactions, visuals, animation, typography—everything. If a feature has a problem in one of these areas (f.e. low color contrast), it may fail to meet its goals completely. Something can look good without being good. This makes recognizing good design much harder than recognizing bad design. Don’t design to impress designers. If you ask experts to review a design, scope that request. Otherwise you may get a lot of in-depth feedback on a feature that’s to be thrown out anyway. Team compositions may not always match with a good design process. You may, for instance, find yourself on a team with backend engineers where ideally you’d spend a few months doing research before implementing anything. If that’s how your organization works, now is the time to correct that for the next team. For this one, make the best of it. The engineers may actually find it useful to do some R&D while you’re doing research. If the product manager insists on working agile, maybe you can put only part of your design capacity on iterative development, while the rest uses the outcomes in user research. Reserve time for your team for kickoffs, critique sessions and user research conclusions. People don’t care about expected user research outcomes and challenge you most on unintuitive results. Ignore any separation between design and front-end engineering. It’s kept up to justify higher engineering salaries and to protect people’s professional identities, but it’s not real. If you can build a design system in a design tool, you can (learn to) write CSS. Imagine that print designers would hand off their InDesign files to engineers to recreate the whole thing in another file format before sending it to the printer. That’s what we’ve gotten used to with web design, even if that separation didn’t exist until the mid 2000s and even if writing CSS has only gotten easier. Even having been one of the formal experts on the topic, I still can’t give a good definition of ‘design system’. I do know that a component library should live in code, accessible to the whole team via a website. And that there’s no shame in having only part of it in the design file. Many component libraries are rigid, as they’re built for other companies’ needs. Using such a library is fastest if you don’t need to bend them to your needs. As soon as engineers start struggling to get custom features to work within existing frameworks, you lose the speed benefit, as they’re wasting time on basic stuff that should otherwise take barely any time at all. Learn about design abstractions beyond what your design tool offers. Design frameworks are abstractions and knowing their ingredients is useful for creating your own. (CUBE CSS offers a good start!) Write about the things you learn. Only real blogs are useful for this; don’t surrender your work to platforms like LinkedIn or Medium. They lock out readers and don’t let you archive your articles like you want to. Don’t be dogmatic in design. Every now and then I post on this blog, mostly about design and the web. Get the latest posts via RSS, Mastodon, LinkedIn or Bluesky. For premium treatment, sign up to my design newsletter: Your email Subscribe By subscribing, you agree with Buttondown’s Terms and privacy policy. What do you think about the above?