Each time you visit a web page for the first time, your browser looks at the front end code and assembles the files in a way a user can interact with. Since this process translates code into something meaningful, it’s an incredibly critical part of the website redesign process.
If you’re starting out as a front end developer, or just curious about what goes into making a top-notch custom website, this article should give you an idea of what a successful front end development process looks like from start to finish.
Planning: Don’t Skip the Foundation of a Website Redesign Project
One of the most important aspects of front-end coding is planning and for proper planning, you need to obtain as much information as you can.
Coding begins long before you get the final designs (aka: comps) in front of you. As a front-end coder, make sure you are involved in the process early to gather requirements and understand the functionality for the project. This way you aren't flying blind when you get twelve designs and your Project Manager says, “Go.”
Now that you have the big picture let’s break it down further.
The Kickoff: Ask UX and Functionality Questions
Ensure you actively participate in all kickoff meetings, if possible. If that’s not an option for you, be sure to thoroughly read over the meeting notes to understand the client’s expectations. It’s simple. The more you know going in the more efficient and cleaner your coding will be.
Ask questions. Sometimes it can be hard to think of things you don’t know. Start with something simple and let it flow from there like:
- “What does this button do?”
- “When someone scrolls should this stay on the screen or scroll away with everything else?”
- “How editable is this content going to be?”
The more you ask, the more you will know and the more efficient your coding will be.
Development Check-Ins: Collaborate with the Team
Be sure to look at the wireframes and design comps before they are sent to the client.
Based on the designs, it is your job to ensure budget estimates are accurate and within your ability. Check-ins are a perfect time to speak up with any questions or concerns you may have.
Remember, you’re not telling the designer what to do, you’re working with them to look for potential issues. For example, if there is a grid of particular content like a list of bios, make sure the names aren’t all the same placeholder. You need to know what happens when real content is implemented. “Jane Smith” has a lot less letters than “Cassandra Worthington” and those letters will need to go somewhere.
The Set-Up: Module Naming Conventions
Once all the designs have been approved, break it down further. It is important to get all of your global elements out of the way.
Start by breaking your web page content into modules and naming elements from a high level.
Establish your naming conventions. Whether you use semantic class names or literal, any small variations could cause the site to change. From my coding experience, I’ve seen intros moved to the footer and bios changed to services.
Your coding can never be perfectly future proof, but ensure the next person who works with your code can make sense of it. (That next person may even be your future self, so you may also be thanking yourself later.)
Once you get everything identified and your tasks are broken down it's time to start coding.
All Systems Go: The Coding Begins
Start with the homepage because that makes sense, right? Wrong. Think inside out. This is where the “C” in CSS becomes your best friend.
Begin with the elements that require the least amount of specificity like flow content. Get your <p> and <h#> elements styled, and anything else that doesn’t have a class name.
Next, form your layout and configure your containers, rows and grids. Then, move to your other global elements like your headers, footers, or anything that shows across multiple page templates.
Now it’s time for the one-offs and customized areas. Usually, this is most prevalent on the homepage but we still aren’t ready to go there yet.
Finally, finish up every content module and then move to the homepage. The reason front-end developers save the homepage for last is because it is the most unique page that offers “wow factor.” (This page also is the most likely to receive those last-minute edits from clients who want to make sure their new website gives great first impressions.)
Quality Assurance: They Make Websites Better
Quality Assurance, by definition, is the examination of a website or web application to try and uncover any flaws that might have been overlooked during design and development.
Essentially this process involves a person or team pointing out your mistakes. As developers, it’s easy to get your feelings hurt when you receive a list of 75 things you may have done wrong during development. But, in order to deliver a functioning website, quality assurance is a necessary step. It shows you’re invested. Remember the flaws that are pointed out are not about you, they are about the project.
Don't think of QA bugs as things you did wrong, but ways to make the final website better.
The Finished Product: Celebrate
At the end of the day, no matter how many bumps and bruises you and your project receive along the way, launching a new website is something that you can be proud of.
Endless hours of planning, coding and lists of quality assurance edits will help you get there. Just do your best. No process is perfect but as long as you receive as much information as possible and start with a plan delivering a beautiful website to the client is within reach.
Comments