TL;DR
Doing your due diligence in a website’s planning and design stages can save countless development hours and headaches. In this guide, I will detail the 10 stages I typically go through before touching code.
Table Of Contents
10 Stage Process
1. Creative Brief
2. Feature List
3. Sitemap
4. Wireframe
5. Prototype
6. Design System
7. Component Flow
8. Optimize Images
9. Development Notes
10. Trello Production Board
🏁 Introduction
Let's be honest, starting a website or app from the ground up is pretty daunting. There is a lot to consider, what with all the possible tech stacks to use, where to host it, and does it make sense to use a framework or not...
Today, however, I would like to take a step back and focus on what happens before we ever open WebStorm or Visual Studio Code.
Before we can code, we need to know...
- What features to build
- Why they are important
- Who they are important to
- How to align on our vision with the decision-makers for the project
- How to easily transition from strategy to design to development
In this guide, we will cover how I approach implementing strategy and design in 10 key stages.
It may seem like a lot of steps, but each one clarifies the goals and direction of the website in a meaningful way. By the end there should be little to no changes or questions once the programming begins.
Who This Is For
Someone who is starting to freelance and wants to help clients with the site's design & content + development.
The "Web Gal/Guy" responsible for all things "Our Website/App" in a small company/startup.
Students looking to level up their group projects and portfolio work.
Developers who want to understand the decision-making behind many submitted tasks in Jira / Trello / Basecamp / Monday.com / Asana
Important Notes
1 — This is my full process, but it's totally valid to streamline it for very quick/small projects.
2 — This guide does not outline specific UX tactics, like personas or user interviews. These are still great to do if you can and I will indicate where they can be slotted in.
3 — The following stages are based around a "Waterfall" methodology, as opposed to "Agile" which is a favorite in software development.
Both are awesome, but I personally like "Waterfall" for client websites because the stages are so clearly defined.
If you are curious to learn more, check out this resource.
My Background
Since early 2020 I’ve been studying and working in front-end web development. Most recently working as a React Native developer for an IOS fitness app.
Before that I worked for about 5 years as a multi-disciplinary designer and team lead at a design agency.
From 2018-2020 I focused solely on web design, account management, HR, and managing our global development teams.
It was during this 2 year period that I really got an appreciation for the "process of web design”.
10 Stage Process
Creative Brief
A creative brief (also know as RFP or project brief) outlines the details and things to consider for the project. This is usually the starting point to understand what the project is about.
They are awesome and I always review them multiple times to fully understand what is needed. Usually, I will have at least one follow-up call to clarify my understanding of it.
Sadly, we don't live in a perfect world
It is all too common to not get one of these at the start of the project. Often times the project kicks off with "I want a modern & unique website" or "Marketing is looking to up our traffic".
For those who are not sure... this is not enough info to go on. I would not know how to build you an effective website, based on "it should be modern".
It is totally ok and honestly imperative to ask more questions. It shows you are thinking from a place of strategy and experience when asking to formulate a creative brief with your client / boss / teacher.
Some Key Questions to Ask
Q1 — Why are you looking for a new site or refresh?
Don't make assumptions. Have the other person tell you their "pain points". (What they are looking to solve.)
Q2 — Who will be visiting this site? (Target Demographic)
You are really not building a website for your client/boss. You are building it to meet the needs of their customer.
A medical website should be built differently if the visitors are experienced doctors vs patients who are not sure what they are looking for.
Q3 — How will you know if this website is successful? (Key Performance Indicators)
You won't know if you did a good job if the project goals are not clear. "It looks great" is sadly not a measurable metric of success on its own. It's just one way to get there.
Also, believe it or not, not everyone is looking for high traffic as a priority metric. Sometimes it is more important to have a small targeted audience with a very high rate of conversion.
Example: Account portal for existing customers that makes it easy for them to update billing info, cutting down 40% of technical related calls.
Q4 — Which of your competitor's do you think have effective websites?
Yes, do your research as well, but they are the experts in their given market. Let them give you examples of who they think are doing a great job. Competitor sites can give you a lot of insight on what to do or to stay away from.
Our clients might not know how to verbalize what "modern website" means. However, you may notice that their competitor's website has online ordering, while they only have PDF menus. It was what they were getting at, but you are making it an actionable solution.
Q5 — What are your immediate business goals and where is your business going in the next 2-3 years?
Being able to consider solutions for both current and future goals is a huge value add.
This also allows you to help them prioritize features. Maybe they want a shop page, but they won't have the team to support it for another year.
This is a great opportunity to look out for them and save some money/time upfront. Yes, you might make a little less up front, but you will gain a happy client for life.
Q6 — When is the launch date?
Everyone wants their site up ASAP, but sometimes that means in at the end of Q1 in 3 months and other times that means next week. It is important to know which it is.
Q7 — Who is my point of contact and who will be approving stages?
If you are working with a new team or group of clients this is super important. It can mean the difference between staying up all night making edits because one person said they don't like a core feature.
(Big difference between feedback from the CEO funding the project and a junior associate who can't authorize final decisions.)
Q8 — Do you have existing brand/development guidelines?
This will greatly help specify what design and development solutions can be made and what is not allowed.
Feature List
If it wasn't specified in the Creative Brief already, I use the feature list to roughly outline the scope of the project. I like to do this in Trello as a checklist, but it can easily be done in a Word/Google doc.
Things to consider including...
- Roughly how many pages there are
- Calling out big sections like blogs, account portals, or payment functionality
- If there are animations and roughly where are they
- Does the site need search capabilities or not
This does not need to be incredibly specific or even final. There are stages dedicated to that later on. This is just a way to get some idea on paper of what is being planned.
Depending on the project this can happen at different stages...
If it is a client project I will include this as part of the proposal to help align on the size of the project.
If it is a school or work assignment this is my first pass at understanding how it should be built. It makes it easier to ask questions too.
Sitemap
A sitemap (in the design stage) is a visual representation of all the pages on the site and how they connect to each other. It is incredibly valuable in working out IA (information architecture) and how the user will navigate the site.
Sitemaps should not be overly complex. They just have to communicate the page names, any major sections on those pages, and how they connect.
I really like this stage, because it allows me to quickly align the site structure with my team or client. For something that is so simple looking, it is very very important for working out the user experience for the site.
If you are doing a deep dive on User Experience, that should start happening right before this stage. Insights gathered from interviews, personas, and A/B testing can help inform the sitemap and future stages.
Lastly, for this stage and the Wireframes and Prototype stages, I use and recommend Figma. You can learn more about this awesome free tool, with my workshop below.
Wireframe
This is the first official "design" stage, where we drill down a little deeper than the sitemap.
Now that we have a high-level view of the website, we can use the wireframes to sketch out where sections and features will live on the page.
The keyword above is "sketch". Wireframes are not meant to be pixel perfect. They are not final. What they are is a way to quickly test out and present ideas relating to content and functionality.
Example
Let's say you have 6 images to show on the page. You can approach the layout in a few ways.
You could display them in a grid, with the images opening up in a lightbox.
Another option is a full-width carousel that cycles through the images every few seconds.
The wireframe lets you quickly layout both options, without creating pixel-perfect designs that take hours to complete.
Things I Consider With Wireframes
Wireframes are not the final design! To help communicate this I always create them in black and white, with generic fonts and shapes for images.
Clients and team-members reviewing the wireframes should just be focusing on content, features, and rough layout.
Because wireframes are a great way to proof content, I always try to use "near to final" copy and not lorem ipsum text.
While they can be sketches on paper, I like to build simple and clean layouts in Figma. If a section does indeed stay, I won't have to start from scratch when designing it for real.
Prototype
This is where we get to truly implement all of our research and planning. It's ok if you are not a designer. The following sections can also be a helpful guide as what to look for in a design partner.
The prototype design (also called High-Fidelity Mockup) is where I will show how every major screen will look before we begin coding.
This is where we work out the final design and user experience solutions. It is at this point where we apply things like brand colors, graphics, and a final layout.
Depending on the complexity of the design and project requirements, I will also create mobile-specific screens. It makes coding with a "mobile-first" approach a lot easier.
I also find it helpful to position all the pages in the same structure as the sitemap or user flow.
Programs like Figma makes it really easy to do this and draw lines between them on how they connect.
It gives another opportunity to validate if the path the user is supposed to take for a particular action makes sense.
Design System
The prototype design should not only look good but make the design and development process easier.
It is important to create a Design System, which holds any major and/or repeatable styles, components, and assets.
For example, a design system will usually have any typography styles used and the full-color palette. Components like navigation, footer, or a button will live there as well.
This way if there is an edit, you only need to make it once in the Design System. If set up correctly programs like Figma will update that element or style across the design automatically.
It is also super helpful when you do start coding. I use the style guide as my CSS blueprint which makes setting up color variables and typography elements so much easier.
The design system can come in all sizes. You can start small and then grow it as your project get's more complex. Below is a general list of sections I generally use in the design system. (Not all are always applicable.)
Mobile & Desktop Grids
For example a 12-col grid for desktop and a 2- or 4-col grid for mobile.
Colors
This includes any brand colors, hex codes, variable names, and their tints/shades.
Typography
This includes h1-h6 headlines, body lg/md/sm, and email versions because only default fonts are allowed in marketing emails.
Buttons (Website & Email)
I try to include any button on the site with default, hover, active and disabled states.
UI Components
This is for major repeatable elements that are not navigation. Things like logos, card elements, form fields, hero banners, etc.
Navigation
I have found that navigation components can often have a lot of states and sometimes many types for larger sites. So they get their own section.
Icons
Any UI specific icons that are not the logo. Things like arrows, chevrons, menus, profile silhouettes, etc
Effects
This contains styles for Box Shadows, Inset Box Shadows, Layer Blurs, and Background Blurs.
Component Flow
Recently I have started building "Component Flows" diagrams for my React projects. It is a way to visually plan and track the structure of React components.
The top-level shows the main folders inside of the standard "components" folder. Each of these folders is color-coded.
The tree under it shows how the components will be structured in the app. The components are also colored to match the folders they live in.
This is incredibly helpful, because not all components that appear together, live in the same folders. For example, the <ButtonPrimary /> component appears in several different sections, but its file lives in the "UI" folder.
This makes it much easier for me to structure my app and then later find things during development.
Optimize Images
A huge issue with many website's page performance is that they are using large images. If a homepage has 10 images on it and each is 3mb, then that page has to download 30mb. That is is bigger than some full websites!
Ideally, most images should be under 200kb or at least 650kb if it is a large hero image. There are always exceptions to the rule, but even if this works for 80% of the images that is a huge performance save!
Using Photoshop or Adobe Lightroom, I make sure the image resolution is 72dpi and bring the width/height down to double the needed size.
Monitors can't process any more than that, but many cameras shoot at 144dpi or even full print quality of 300dpi. This is undeeded added weight to the fie.
The 2x size can help if, I need to use the image for retina displays.
This is done before I bring it into Figma, allowing it to run quicker and for production to already starting with optimized files.
Before I upload to the site I will also typically run the images through tinypng.com. This site does an amazing compressing the images with very little file decay or artifacting. As you can tell in the image above, the change is night and day.
Development Notes
Once the design is done and the assets like images are ready to go, I like to also add developer notes to the design.
This is made really easy by Figma, where you can drop a comment pin anywhere on the design and even tag other people in it.
It is a great place to add reminders for animations, API references, and coordinating between co-workers.
Trello Production Board
Technically this step can start at the beginning. I find it so valuable to track the project from design through development on a Trello board.
My go-to workflow is a Kataban methodology, where tasks are tracked in 3 lists — "To Do", "Doing" and "Done".
Often times I will expand this out to have the following lists in order...
1. MISC/Resources: API keys, logins, brand guides, and things that will be helpful throughout the project.
2. Future Features: This holds anything that will be great to add if we have time/budget, but are not critical to the launch of the site.
3. To Do: Pending items that are critical to launching the site. Often times this is tagged with the person that will be working on it and a due date.
4. Doing: Tasks that are actively being worked on.
5. Review: Items that are ready for review by a teammate or a client. These might go back to "To Do" or "Doing" if there are edits.
6. Done: These are items that have been fully completed. It is great to track the progress of the project and show clients how much was already completed.
Summary
I hope this was helpful! It may seem like a lot, but as you can probably tell, each stage builds on the next.
I am a firm believer that it is faster to spend more time doing it right up front, then redo things later on because of miscommunication.
Is there anything on isn't on this list, but should be? I'd love to learn how you keep projects, expectations, or communication on track!
Happy (Strategy, Designing) Coding! 🤓
Thumbnail designed with Figma
Top comments (3)
Thanks.
Good post!
Thank you!