When I was first thrown into leading a team and was mentoring our first junior hire, he asked me a question.
“Hey Paul, what’s your approach to building websites?”.
I explained to him the gist of how I approach things but also promised to write it out in a bit more detail.
That was 2 years ago.
Now I am finally sitting down and writing it out. This is very much tailored towards building a website from scratch but my approach is pretty much same regardless.
So without further ado, here it is, how I develop websites.
Step 1: Initial look
When a web design lands on my desk. I spend about 30 minutes breaking down the design, jotting down any interesting parts and questions.
Things I am looking are:
- Is there anything that seems really complicated?
- Are there responsive designs? Or will I need to adapt them as I build?
- Is there some kind of system in place? Are there any single use values?
- Is it, at first glance, accessible? Do the colours have appropriate contrast? Is the text an appropriate size, are touch points large enough?
- Is there anything that I am unsure about?
I send any questions I have back to the designer/client/stakeholder. It is very important to get things clear from the start. Everyone needs to be on the same page about what is to be delivered. Two people having different assumptions on deliverables can easily derail projects.
Once all of my questions have been answered and it is clear what needs to be done, I start breaking the design down.
Step 2: Breaking the design apart
With the requirements clear, I duplicate the design file and start breaking the design into individual sections. I draw boxes around each element in the design and jot down what HTML elements best represents them. I used to print these out and use pen and paper but nowadays I just use Figma to be less wasteful.
After breaking down the design I should have a nice list components to be built. Now it’s time for execution. I take it one component at a time.
A note on execution
Execution is not about getting everything perfect in one go. I work iteratively. I work fast to get a working prototype then I iterate and refine it in cycles. I find that I am much faster and produce higher quality doing it this way. It normally takes multiple passes before I am fully satisfied.
Doing this also means you can show progress earlier. Showing progress is a very important skill to have as a developer. It gives your stakeholders confidence in your abilities and it lets you gather feedback faster. Don’t disappear for two weeks trying to get things perfect when, with the right feedback, you could’ve finished it in one.
Step 3: HTML
With a breakdown finished I should have a pretty good idea of all the little components that make up the design. This is when I start coding the HTML. I also add classes, placeholder content and any other attributes as necessary. I like to name my classes using BEM.
Here is what I am thinking about while doing this:
- Is the HTML I’m writing semantic
- Are the classes following the established best practices?
- Is there just enough elements to implement the design nicely? I try to use not too much otherwise it becomes messy and not too little that it gets really difficult to do.
- Are there any opportunities to componetise parts of the design?
Step 4: CSS
With the HTML out of the way, I can start focusing on my favourite part of the process, writing CSS.
I like to use SCSS if I can. I separate each components CSS into it’s own SCSS file and merge everything with a bundler.
If you’ve done all the ground work and the HTML is set up well then styling should be pretty straight forward. The structure and classes are set up so all you need to do is add the CSS to make it look nice. Straight forward doesn’t mean easy though. I usually go through a few revisions before I end up with something that I like.
This is also when I start thinking about responsive design.
Responsive design
Mobile first is how I like to start. I go through the design and start writing all of the CSS needed to get the component matching it. Once that is done then I take a classic approach to making sure it is responsive.
I start increasing and decreasing the viewport until the design breaks.
The size that it breaks becomes my breakpoint. And that’s where I fix the layout. I repeat this until the page is looking good at all sizes between 300px and 4k. Why those sizes, I’ve found they are the lower and upper limits of screens sizes that are used by users. But feel free to modify these based on your unique use case.
I use a lot of clamp() in my CSS for fluid values. This cuts down the number of breakpoints I need to use by a lot. This is especially useful for typography and spacing.
What about pixel perfect
I don’t believe in ‘pixel perfect’, not in every instance but I do believe that it is your responsibility as a web developer to build the closest representation of the design based on the information given to you.
It’s unrealistic to expect a design to be pixel perfect at every possible screen size and device but if the design is 1440px wide then the final website should be pixel perfect when viewed in a window that is 1440px wide. That’s just being a good front end developer.
Once I’m happy with the styling, I start testing the design. I make sure:
- It’s accessible
- All possible states like hover and focus etc. are covered.
- The design does not break at any screen size. (I literally drag the window back and forth to see if it breaks anywhere).
At this point I should have a very nice looking component. But sometimes a component has interactivity, which needs JaveScript.
Step 5: JavaScript
I work primarily on websites, so most of the Javascript I write is around DOM manipulation to create animations or toggle effects. Sometimes I’ll need it to make some API calls to get and manipulate some data but that’s about as complex as it gets.
Because of that I try not to do anything fancy with JavaScript, I use a build process created with WebPack to minify, concatenate files and handle cache busting.
JavaScript is where a lot of things can go wrong so accessibility and performance is top of mind when I start writing my JavaScript. I begin with a ‘progressive enhancement’ approach. The site should function perfectly fine without JavaScript.
Step 6: Dynamic logic
Once the design has been fully built with nothing but HTML, CSS and JS. I make the changes necessary to include the dynamic logic. For a WordPress site this would be PHP or React if I’m building a block.
I remove any static content and data and replace it with the dynamic values and logic.
The best part about this is that by this time I can purely focus on the dynamic logic without worrying about the styling and front end functionality since that’s all done beforehand.
Step 7: Test, test again, maybe refactor
I do quick little tests every step of the way but I do one big test here once I feel like it’s complete. I try to cover every scenario I can think of, not just the happy path.
I document these tests. Just screenshots, save them in a document and write a sentence or two explaining each test, nothing too complicated.
It will be here where I might realise that there are places in the code that I can improve upon. If the benefits outweigh the time it takes then I’ll also refactor the code with those improvements. In order for me to consider refactoring worth doing; the benefits need to either:
- improve the user experience or;
- make it a lot easier for developers to make changes in the future.
Refactoring because I feel like ‘making the code cleaner’ is a waste of time.
Final thoughts
So that is a bit of a overview to how I approach turning a design into code.
The key takeaways from this are:
- Always think about the accessibility of what you ware building
- Work in layers. Break it down, finish one layer at a time and then keep building upon it.
- Iterate, iterate, iterate. Get an MVP out fast, show your progress, get feedback, revise and polish. Then do it all over again.
I don’t think there is anything special with my process. I like to keep things simple, keep people updated and get feedback early. That’s really it.
PS. I thought about having examples of each step but thought that would make this take way too long so instead I’ll be showing you an example in another post in the future this post. Here’s a sneak peek of the design we’ll be breaking down.
Exciting?