In programming, there's a principle called the Single Responsibility Principle. It states that each piece of code should do one thing, and do it well. This ensures that the code behaves as expected, without any unintended side effects. I’ve adopted a similar approach to web design, breaking down the process into five distinct stages, each focusing on a specific aspect of the design. This structured approach helps me create website designs that are both functional and visually appealing.
In the past, I struggled to complete projects to my satisfaction. Sometimes, I’d end up with a visually appealing design, but the code would be messy and difficult to maintain. Other times, the code was clean, but the design felt uninspired or generic. Even when I did manage to finish a project, I often found myself wishing I had approached certain aspects differently—whether in the design or the functionality.
By following a process that allows me to focus on one aspect at a time, I can refine my ideas and make informed decisions before moving on to the next stage. This methodical approach makes it easier to create a cohesive and polished final product. The process includes five stages: research, sketching, wireframing, mockups, and development. Each stage builds on the last, guiding the project towards a successful and satisfying conclusion.
Laying the Foundation: Research and Planning Web Design Project
The research stage is where I define the project in detail. Projects often begin with vague ideas—perhaps a client says, "We want to rebrand our site," or I come up with something like, "I want to improve my local bus app." While these are excellent starting points, I need more specifics to design the website or app effectively. First, I need to understand who the user is and what their goals are. This gives me insight into what the user expects from the site. I also need to identify the information the site will provide or the features the app will include. Understanding my audience helps me generate ideas and prioritize them. By the end of this stage, I aim to have created two key documents: the mood board and the site map.
The mood board is a collection of fonts, colors, images, illustrations, and textures that communicate the final look and feel of the site. I also include screenshots from similar projects, which I use to pick out colors using the eyedropper tool. I like to add a box showing the color with its hex code printed inside. After taking the screenshot, I often return to the site to find the fonts used by inspecting the code. I then find the font (or a similar one) on Google Fonts and take a screenshot that includes both the font name and a sample. While I don't always include illustrations and textures, they can add unique elements to the project. Some sites use illustrations when real-life images aren't available or wouldn’t be relevant. Textures can also make a background more interesting than a flat color.
The site map is a tree diagram that shows the hierarchical relationship between pages. The home page serves as the root, with the first layer consisting of navigation menu pages and other pages accessible from the home page. The next layer includes their subpages, and so on. At this stage, I also start thinking about the content that will go on each page, laying the groundwork for the design to come.
While sitemaps are excellent for organizing information on websites, they may not be as effective for applications where interaction is a priority. Applications require a bit more planning. I begin by examining the project as a whole, considering the different roles the application will need. Some applications require administrator roles and multiple levels of permissions. Next, I break down each feature individually, identifying the data types required. This leads to compiling a list of user stories, organized by data type and, within each data type, by role. Finally, I create a flowchart for each user story to visualize how users will interact with the app.
By the end of this stage, I have a clear understanding of the project’s scope, including the time and effort required. With the site map or user flowcharts completed, I can choose a productivity tool like Trello or Notion, though I often find that simple checklists work best. At this point, the project's goals are set, and these won’t change. While the site map and user flowcharts may evolve during the next stages, they provide a solid foundation for designing the details of each screen or page.
Clearing the Creative Clutter: The Importance of Sketching in Web Design
The sketching stage is all about generating as many ideas as possible and clearing out the less viable ones. For each unique page or screen, I aim to create at least 16 layout sketches, all done on paper. In his book "Steal Like an Artist," Austin Kleon explains that while computers are great for presentation, they can be cumbersome during the ideation process. I've found this to be true. When working with pen and paper, I find it much easier to get my ideas out without the constraints of design software.
Sketching is a balance between speed and clarity. I want to get all my ideas down quickly, but they sometimes come so fast that I can’t capture them all before they slip away. However, these sketches won’t be useful if I can’t interpret them later. To create clean, quick sketches, I use a simple system for different types of elements.
First, I work on grid paper, which helps me draw clean sketches. I divide each sheet into thirds, with three boxes spaced one square apart and one square from the edges. These columns may contain one or more page sketches. If a page is short, I might fit another page in the same column, using a single square to separate them.
For the elements, I use boxes one square in height to represent headings, lines for body text, pink boxes for buttons, blue boxes for images, purple for videos, and green for any other interactive media. I use Pilot Frixion Erasable pens and highlighters for these sketches.
Sometimes, generating 16 ideas for each page or screen can be challenging. When I’m stuck, I break the page down into sections and come up with 16 variations for each section. This approach allows me to focus on one part of the page at a time rather than the whole layout.
In larger projects, it’s especially important that these sketches are clear and easy to read. Sketching so many layouts can be time-consuming and mentally exhausting, so I usually limit myself to about two hours a day for this stage. It can take weeks to finish all the sketches, and by the time I revisit them, I might not remember what I was thinking when I drew them. To help with this, I sometimes leave notes in the heading boxes, hinting at what kind of copy or content belongs there.
The purpose of creating so many sketches is to explore layout ideas for the final design. By the end of this stage, I’ve decided what content will go on each page and have a range of ideas for how to place it. At this point, the site map is also finalized, and both the site map and content outline for each page are set. These are two more decisions I no longer need to worry about as I move forward.
Transforming Ideas into Structure: The Wireframing Stage
In the wireframing stage, I take four sketches from each page or section and build them in Figma. I look for patterns in the sketches and often choose one sketch from each major idea, ensuring that the most promising layouts are developed further. At this point, I work exclusively in grayscale, focusing on structure rather than color. I add headings, body text, and placeholder images according to the layout in the sketch. As I build the wireframes, I’m also considering the typography styles and components the project will require, although I keep the wireframe itself simple, using a single sans-serif font without any unique styling. I make a note of any patterns that can be turned into style variables or reusable components later in the mockup phase.
The primary goal of this stage is to finalize the content layout and organize it effectively on the page. If I’m working on a client project, I create the initial wireframe with placeholder text and images. I then send one of the four variations to the client, providing them with a template to use for filling in the content. My clients are mostly non-technical and prefer that I handle the technical and design decisions, so feedback during this stage is usually minimal. However, if a client does request significant changes, it typically involves adding new sections or information. In such cases, it’s usually best to continue with wireframing rather than returning to the sketch phase.
For placeholder content, I use gray boxes with appropriate icons, sometimes in different shades of gray to distinguish between types of media. Once the client sends back the content, I copy and paste the headings and body text into the wireframe to ensure it fits well within the design, making any necessary adjustments. I also note any changes needed for the media provided by the client. Often, I receive portrait-sized images taken on the client’s phone, but for website design, I prefer landscape formats. I compile a list of images that need to be cropped or resized.
By the end of this stage, I have a black-and-white mockup of the site, complete with some placeholder media. The content is finalized at this point, so the only remaining design consideration is branding.
From Wireframes to Visuals: Crafting Detailed Mockups
In the mockup stage, I take the best variation from the wireframe phase and add colors, typography styles, and final media. I also create reusable components based on the patterns identified during the wireframing stage. By this point, all the major decisions about content and structure have been made. Now, my focus shifts to applying branding and refining the visual design.
Before I begin creating the mockups, I establish a design system. The design system contains documentation for the colors and typography styles used throughout the site, along with any components and their variants. For simple websites or applications, I typically keep the design system on a
dedicated page within the mockup file. In fact, I might only use a single Figma file for the entire project, with different stages organized into separate pages. However, if the project is large or likely to expand into multiple sites or apps, I create a separate design system file, allowing multiple files to import its contents as a shared library.
I've found that building the entire design system before creating the mockups is often inefficient. The wireframes give me a rough idea of what components I'll need, but I won't know for certain until I start designing the mockups. There’s no need to design every possible component upfront. Instead, I begin by adding the color palette and typography styles to the design system, then create essential components like buttons. Every project I've worked on has required buttons, so this is usually the first component I design.
Once the basic design system is in place, I start designing each page according to the chosen wireframe. As I complete each section, I look for reusable elements to add to the component library in the design system. For example, the header and footer are typically the same across all pages, so I create components for each and use them consistently. If I need to make changes to the header or footer later, I simply edit the component in the design system, and the updates automatically propagate throughout the entire site design.
By the end of the mockup stage, I have a detailed visual representation of what each page should look like. All visual and structural aspects of the project are finalized, leaving only the task of building the pages and implementing functionality with code. I also have a comprehensive design system with documentation to ensure consistency between the design and the live site.
Turning Mockups into Reality: The Development Stage
The final stage of the project is development. In this stage, my primary objective is to transform the mockups I created into a live site or application. My main focus is on writing clean, maintainable code. The documentation from the design system provides clear specifications for colors and typography, and Figma offers default specifications for spacing, which I follow closely.
If I’m building the project in WordPress using Oxygen Builder, the process is straightforward. I use the Oxygen Builder UI to replicate the design. While this may seem like duplicating work, Oxygen’s interface is more complex than Figma’s because it combines both visual and technical aspects of building a webpage. Having the design finalized before I start building the project pages is incredibly helpful, allowing me to focus on the technical implementation.
For other projects, I prefer to use Next.js, organizing the project with the app and src directories. Inside the src directory, I create a library directory, where I store all the variables and components used on the pages in the app directory. Within the library directory, I have components and utilities folders.
The components library is organized into directories for each component, with each directory containing the component file, a stylesheet, and a types file. If I’m building an application, I also include a test file for each component.
The utilities directory contains SCSS partials with variables and mixins used across components. Some of these correspond to the variables, styles, and components from Figma, while others are custom styles I find useful. I strive to keep my code as DRY (Don’t Repeat Yourself) as possible. This directory also houses miscellaneous types and functions used by multiple components, while more specific types and functions stay within the component’s directory.
By the end of the development stage, I have a fully functional website or application deployed to the appropriate platform. For WordPress websites, I use Amazon Lightsail, and for my Next.js projects, I prefer AWS Amplify. The code is structured in a way that’s familiar to me, making it easy to make future updates or changes quickly.
Adapting the Process: Balancing Flexibility with Quality
The process I’ve described here is undeniably time-consuming. Some might even argue that parts of it involve duplicate work. However, I find it incredibly valuable to slow down and tackle one design problem at a time. This methodical approach helps me ensure that each aspect of the design is carefully considered and executed. Unfortunately, this isn’t always possible, especially when working on client projects with tight deadlines.
In an ideal scenario with timely communication from the client, I aim to complete a small, five-page brochure website within about a month. For projects like these, the sketch phase is often the first to be eliminated, followed by the wireframing stage. These stages can be skipped because many design patterns are commonly used on the web, allowing me to rely on established solutions for displaying different kinds of information. I can design the mockups based on these existing UI design patterns, streamlining the process.
For example, if I need to create a section that highlights a business’s or organization’s offerings, it will likely be laid out in two or three columns, with each offering presented in a card format. While it’s easy to think of a design pattern that will work, going through the sketching and wireframing stages helps me explore creative ways to use the design system, making it easier for users to find what they’re looking for. This creativity can add value to the project, even within a more constrained timeline.