Ask any two designers or front-end developers how they approach a project, and they’re likely to give you two wildly different answers. Some prefer to figure things out directly in the browser. Others come up with their best ideas by first designing intricate mockups. Whenever possible, I like to let the project itself determine my approach to planning and building a website’s front-end.
At Code School, we use an internal application built around enabling team members to read, contribute, and improve documentation about the tools we use regularly. While our internal developer, Olivier Lacan, laid the foundation for the application, he worked hand-in-hand with a front-end developer to redesign the user interface. After sorting through the pre-existing codebase and lots of published articles, we were left with a front-end process that’s great for jump-starting projects — and one I want to share with you. The process is broken into the following steps, each of which I’ll walk through:
- Content audit
- Front-end audit
1. Content Audit
A content audit is a list of all the information, media, navigation, and features required on each page of a website, as well as any actions available to the user on those pages. It acts as a project outline that you can continually reference, and if highly detailed, a checklist to help you cover all the bases.
When I began working with our internal application, our team had already published over a hundred articles to the site. In other words, there was a lot of content. Making a content audit early on helped give me a firm grasp of project requirements and incorporate them into an intuitive front-end.
Wireframes are your first chance to experiment with different layouts and arrangements of content. Individually, they communicate each page’s purpose and content hierarchy, while together, they demonstrate user flow and conventions present across an entire site. When working with a team, wireframes are a quick way to share design ideas with each other before spending valuable time making mockups or writing code.
I try to keep wireframes as simple as possible. First, I use Sketch to block out the layout and content, then add in as little text as needed to label what’s on the page. Spending minimal time on each wireframe also helps prevent me from growing overly attached to a particular idea, encouraging lots of experimentation early on.
At a glance, mockups and wireframes do very similar things — they both visualize layout and content. But mockups go even further by adding in colors, typefaces, and various user interface elements. Mockups help breathe life into a design by defining the look and feel of a website.
High-fidelity mockups aren’t always the right tool for job. When it comes to responsive design, you could easily end up making two or three mockups for almost every page — prompting the need for a different approach. Style Tiles let you design individual user interface elements, and combine them later into any mockups you want. It’s also very straightforward to write modular CSS based on Style Tiles, making them a great jumping off point for front-end development.
4. Front-end Audit
Once you have a solid understanding of a website’s front-end, it’s often useful to catalog the different modules and dependencies needed to actually build it. At Code School, we use something called a front-end audit to outline each project’s requirements. Typically these address the following concerns:
- Browser support
- Tools (dependencies)
- CSS architecture
- Notes and ideas
Development is centered around implementing a design in code. This generally involves setting up project boilerplate (i.e. directory structure, dependencies, and build tools) before moving on to markup, style sheets, and scripts. If you’re working with Style Tiles, you can build the individual modules and later piece them together to create larger user interface patterns.
While development comes last in this list, that certainly doesn’t mean a design has to be finalized before writing any code. In fact, I highly recommend jumping into development as soon as possible. Mockups may look pixel perfect as static images, but their implementation won’t always play nice with responsive design and user-submitted content. Encountering these issues early on when team members have made fewer assumptions will save you from throwing away a lot of code.
As web designers and developers, the sites we create are never truly finished. There’s always going to be room to iterate and improve on existing websites, whether it’s improving the user experience, fine-tuning application performance, or building brand new features. Instead of relying on a process set in stone, it’s best to examine each problem individually and then choose the right tool for the job.
Let us know what you think about this process, or how you tackle a project, in the comments section below!