Part 3: Redesigning Webflow.com

Building the website in Webflow

Ryan Miyoshi
Webflow Design

--

Over the last couple weeks, we looked at why we decided to redesign Webflow.com and the process of designing the site.

In this article, I’ll detail how I built the website — for a company that makes a tool for building websites — using that tool for building websites.

Yeah, it’s a little inception-y.

Before we dig in, it’s worth noting that this was only my second project at Webflow, so I’d only built a couple pages in Webflow. I hadn’t even thought about building a whole site yet. So, below I’ll talk about how I approached the build, what I did right, where I messed up, and share some things I learned about how to better build sites in Webflow along the way.

Phase 1: Laying out a framework

The first step, once we had our design and content direction defined, was duplicating the existing site so I could a) work on a separate copy and b) create a new style and class-naming system. Once I duplicated the site, I spent some time ripping out as many of the old classes as possible, which let me start with a (nearly) clean slate.

From there, I decided it’d be most efficient to start with the smallest details and move up, establishing foundational font styles, colors, repeating elements, etc., before building out each page. This approach made the final step of building the pages much faster and easier, since I’d already made many of the fundamental design decisions.

Determining a class naming system

First, I knew I needed to develop a system for naming classes. Having a system for naming classes helps keep thing clean and consistent, which becomes especially important when elements are nested within more complex elements, or when they require variants (such as light/dark).

That’s by no means a Webflow-specific problem. It’s a CSS problem. But that’s part of Webflow’s power: how similar it is to working directly with raw CSS.

Classes work two ways in Webflow:

  1. Global classes: These basically work exactly like classes in CSS. When you add an element to the page, you give it a class name, then style it. When you add that same global class to another element, the styles apply automatically. You can also combine two or more global classes on the same element and receive styles from each, though it’s better to use something we call a combo class.
  2. Combo classes: These allow you to add a class to a global class, creating a variant of the original global class. Let’s say you have a global class named square. You can then add another class to it—say, blue—creating the combo class square, blue. That way, you add a blue background to square without changing the original global class.

So when I evaluated different class naming conventions for Webflow, I looked to the models already prevalent in the world of CSS — including BEM.

BEM (Block Element Modifier) brings structure to the way classes are named by providing context on the class and what it does right in the name.

This system seemed like a lot at first, since it was invented for use in much larger projects, but it ended up being really nice to work with. As the site increased in complexity over time, it allowed me to understand and keep track of all of my elements and avoid duplicate class names.

Beyond this, as more designers join the company and other teammates work on the site, having a system in place will help keep the styles organized and legible.

Recommendations: Keep class names short and use acronyms where appropriate. I originally avoided acronyms, thinking it would be more clear, but it wasn’t necessary and names sometimes got really long. Also, avoid combining global classes because combo classes are a much better system for styling in Webflow.

Typography

Translating my type hierarchy from mocks to Webflow was very straightforward. I first created a new page named Styles, then made an instance of every type style needed, and finally styled them all in one place. The only change I made while doing was switching the units of many of my line heights to ems, which saved a bunch of time that I would have spent calculating and editing over the life of the site. For example, I set my paragraph’s line height to 1.6em in one place, and it instantly looked great at every variant, including mobile breakpoints, where the font gets smaller.

Recommendation: Create a styles page so you can set fonts and other elements all in one place. On mine, I defined all of the type styles first, then all the type colors below.

Colors

I created classes and swatches for all the brand colors and neutral tones so that I could easily change the color of elements in the future. This is a pretty basic approach for dealing with color on the web, which we’re currently working on improving.

Soon we’ll release global swatches, which basically combines swatches with Sass mixins, then gives it a couple shots of steroids. This will let you create a blue swatch, for example, use that swatch to color elements throughout your website, then update the swatch to red, and everything you colored blue will now be red. Pretty cool huh?

Spacing

Though easy to overlook, creating repeatable systems for the most-used spacing sizes was also extremely helpful throughout the build process. I created classes that defined common padding and margin amounts that could be applied to any element down the road.

Buttons

On the styles page, I first created our basic button, using Webflow interactions to animate the arrow, then made variants with every color I needed.

Once I’d built all the button styles, I turned each of them into a symbol, so anyone can easily insert the button style they want on any page.

Components and navigation

Now that I had the foundational pieces finalized, I could use those to then create the responsive and reusable components, along with their variants (e.g., form-blue/form-vertical). To start, I created a new page called Components to build these more complicated pieces of the site on, then built them out one by one, converting them to symbols along the way. Though this was the longest part of the build process, it felt great to get these working perfectly across all breakpoints up-front, and I had a lot of fun with them.

Recommendation: Design systems, not pages. Or, design the system first, then the pages.

Phase 2: Building out the pages

After setting out foundational styles and components in phase 1, there was still a lot of work to be done. Happily, I was able to start creating pages quickly by dropping in the repeating elements like the nav, footer, forms, and other components, which I’d created as reusable symbols. This process literally only took a few minutes, but brought me from 0% to over 50% complete.

Sections

The natural next step was defining the commonly used layouts I’d used throughout my designs in Figma. Flexbox, though incredible throughout the whole build process, was especially helpful here. I created a few loose layouts like section-center, for example, which I set to center everything O put inside of it, and a few variations of two- and three-column layouts.

Flexbox controls, my favorite part of Webflow.

I still needed a system for creating basic layouts quickly that didn’t necessarily fit within the constraints of the sections I’d already created. One of our amazing product designers told me about the concept of a Flexbox Grid, which is a simple system for building flexbox layouts that scale really well. Instead of trying to describe it more, here’s a little graphic that shows generally how it works:

With Flexbox Grid set up, making simple layouts was incredibly easy.

If you use Webflow and use Flexbox, you know how amazing it is 🙌. If you use Flexbox, but write CSS by hand, I’m so sorry. If you’ve built for the web, but never tried Flexbox, we made a Flexbox game you should try right now.

And if you’ve never built for the web, you’ll never need to know how much of a pain in the CSS it is to try to create certain layouts, and you are very, very lucky. Still, play the Flexbox game though.

Custom elements

With help from the fonts, components, sections, layouts and everything else I had made previously, it was then time to build the custom elements of the site.

This was where I had my aha! moment with Webflow. I literally redesigned many areas of the site I’d already built during this stage, because of that realization. As an example: instead of just showing a couple of great tweets from customers, I designed and built a CMS-driven, dynamic component that displays the most recent of our favorite customer tweets, without writing any code, and it only took an hour.

Phase 3: Content

Illustration

After all the illustrations were completed—ok, admittedly, I’ll never stop tweaking these—it was time to export. Using Illustrator (weird, huh?), I made an artboard for each illustration and then exported each using Export for Screens.

Most of the images are SVGs to cut down on file size and because they look great on any screen, but there’s some goofy browser inconsistencies—I’m lookin’ at you, Safari!—with certain types of paths, so many are @2x PNGs.

Videos

Though (a huge) part of what makes Webflow great is how much you can do without writing any code, you can add custom code a few different ways.

With this in mind, we wanted to do something a little custom for the videos throughout the site, which directly show some of the advanced concepts of building with Webflow, so we used a code embed like this one:

<video playsinline loop poster=”placeholder-image.png">    
<source src=”video.mp4" type=”video/mp4">
</video>

I then added the following JavaScript, which waits to play the video until it’s well within the viewport. When the video leaves the viewport, it pauses the video again.

<script>
$(document).ready(function() {
var media = $('video').not("[autoplay='autoplay']");
var tolerancePixel = 250;
function checkMedia(){
var scrollTop = $(window).scrollTop() + tolerancePixel;
var scrollBottom = $(window).scrollTop() + $(window).height() - tolerancePixel;
media.each(function(index, el) {
var yTopMedia = $(this).offset().top;
var yBottomMedia = $(this).height() + yTopMedia;
if(scrollTop < yBottomMedia && scrollBottom > yTopMedia){
$(this).get(0).play();
} else {
$(this).get(0).pause();
}
});
}
$(document).on('scroll', checkMedia);
});
</script>

Additionally, the videos have a max-width of 90% of the viewport width, and a max-height of 90% the viewport height minus 70px (the height of our sticky nav) set, so that no matter what size screen you’re using, the videos are always visible.

Copywriting

I know how to write, but I’m no writer. So as I was designing, my marketing team was in and out the Editor making copy edits, migrating CMS content, and putting that final polish on the written content.

Phase 4: Polish

Interactions

We’re working on a new way to create animations in Webflow called Interactions 2.0, and it’s incredible. For now, I used Interactions 1.0 to create a couple of little animations throughout the site.

There are still many places where I would love to add more interactions and animations. I would also love to write a whole other article about what you can do with Interactions 1.0 (and 2.0) and how to do it, but for now, here’s a GIF of my favorite from the site:

The advantages of working with Webflow—and areas we can improve

Admittedly, some parts of the build process were challenging, and at times, even tedious. But building precise, custom websites — no matter the platform — is a lot of work.

The pros of building in Webflow, however, were several:

  1. Code-free development. For one, I’m not a coder. To be fair, I (like many designers) can write a fair amount of HTML, CSS, and JavaScript, but if I were hand coding this site, it would have taken me a lot longer. My strengths are in design, not development, and Webflow bridged that gap for me.
  2. Code-free content editing. Because the site is built in Webflow, anyone on the team can make edits and updates to the site without going through me or having to file a GitHub issue. This makes updating and maintaining the site much easier for the entire team.
  3. Speed. This whole redesign process — from conception to completion — took just three months, and only Barrett and I worked on it full time. And the build itself, which came last, only took me a couple weeks.

At the same time, I ran into some frustrations with Webflow that I’m glad we’re working to improve this year:

  1. Reusable components. At the moment, you can’t copy and paste elements from one Webflow project to another, which means that our styles and basic building blocks can’t be easily transferred from our new, main site to our other sites (e.g. help center, template marketplace, and landing pages). This is something both we and our customers want, and happily, we’re working on shipping this as soon as possible.
  2. Naming classes. Though this is a problem with CSS in general, that can’t be an excuse to not seek improvements, and we’re currently user-testing a “class-naming optional” workflow that will make working in Webflow faster.
  3. Sass-style variables. It’d be nice to have more variable-like options in Webflow, like the global swatches feature that we’re about to release, for example.

These basic pros and cons only scratch the surface of what it’s like to work with Webflow, but with all the improvements on the horizon, I couldn’t be more excited for what we—and more importantly, you— will able to build.

To stay up-to-date with the Webflow design team, follow us on Medium, Dribbble, and Instagram.

--

--