Stop handing off concepts and start designing real products with Webflow.
I design products, prototypes, and interactions in Webflow. It’s throw-away code (mostly). It’s clunky for lots of screens. It’s slow to get started. It’s not super collaborative. It’s expensive for teams. The code it generates doesn’t really translate to React, Angular, or Native Apps.
Yet I still can’t stop myself.
Other tools are better at visual design. I love Figma, Sketch is great, and still keep Illustrator and Photoshop on my laptop. Other tools are better(ish) at prototyping. I love working in Principle, InVision Studio seems to be making some people very happy, Figma can make quick work of lots of screens, and Framer X… well, I’m not sure how I feel about Framer X yet.
The problem with all of those tools is that they’re really great at making concepts about how a product or app should look and work.
Concepts.
Ideas.
Fictions.
Fantasies.
— bad pun warning —
UI-nicorns.
*ducks*
I get it, though. We need to start with concepts and throw away ideas quickly to get to ship new features. This process and the tools that enable it are great, but I’ve come to realize that handing off those concepts to development always results in rework, miscommunication, UI bugs, formatting issues, mountains of documentation, and design gaps. Designers need tools to concept inside of and collaborate with product, but there needs to be another step after the ideas are there. We need to be able to build it ourselves, or build a version that is based on how code works, not just how it looks. Something that does a much better job of communicating a product design than any amount of gifs, redlines, arrows, comments, Jira tickets, and documentation. That’s where I use Webflow.
Squashing UI Bugs
I started using this process a few years ago when a product I had designed was getting developed in… unexpected ways.
We used Zeplin for specs, I sat feet away from some of the developers on the project, but I still saw odd and frustrating UI discrepancies with each release. Things that I expected to be uniform were misaligned, margins were off, drop shadows too dark, lines too think, yada, yada, etcetera, etcetera.
But the product worked, so the tiny details didn’t get prioritized over other bug fixes and new feature work. Once the new features and stability fixes tapered off, I wanted to be ready with some better comps to fix the UI issues.
Was the issue with the designs and the documentation?
I wasn’t sure if the issues arose because of some dev process or my own, so I resolved to help from my end. I wanted to find a process that would give clearer view of how things should be structured, as opposed to just how they looked.
I wanted to find a process that would give clearer view of how things should be structured, as opposed to just how they looked.
The first attempt was to use Sketch symbols to try to explain how I thought the DOM should be and give clearer measurements.
As you can see by the above gif, I went a little over the top with it. Cool? You bet… Actually helpful? Ehhh, not so much.
The issue wasn’t so much that the dimensions were wrong, per-say, or that the specs were incomplete, it was that I was trying to imagine how to structure the DOM, without actually structuring the DOM.
In tools such as Sketch and Figma, any element can be absolutely positioned. As a result, you don’t have to think through how elements behave with each other. Parent to child and sibling relationships are kept in the back of your mind, instead of something you have to tango and wrestle with.
This is great for ideation, but can lead to bad results when what you think something will do is very different from what it actually does do when developed. Also, redlines are liars. LIARS I TELL YOU. Things are not as neat and tidy as the dev-spec making tools lead you to believe.
Here’s the typical handoff process:
Developer: “It’s 60 px say you, well that’s swell. Let me just make that EXACTLY 60 px like it says.”
Designer: “Oh, hey, I noticed that you made that thing 60px. I know that the design says its 60px buuuuut, it’s really not. It’s actually supposed to grow and shrink with this text, but also needs to be based off of the line height, and also needs to grow to be full width in this use case, and also…”
No one is happy with this process. Designers feel nit-picky, and the developer wishes that it had just been explained correctly in the first place. There’s so much time spent on tiny little tweaks and rework that are all a result of automatically generated real-looking specs that are grounded in a fantasy world where how far apart things are is how big they should be made.
It’s time for dimensions to end
If I was designing gears or sprockets, dimensions would make sense. But I’m not. I’m designing digital products, which are slippery little bastards that are different sizes in different scenarios, and need to be told what to do and what not to do and who their parents are
and what they are not in some cases and what they are are in others.
If you’re relying on redlines, you’re conceding that you’ll have no idea if your design works until someone else has spent a few hours or days on it. Someone who didn’t think through the design like you did, someone who, more often than not, looks at the UI as a necessary evil.
Also, making tweaks after that work has been done is way more expensive. After all, developers aren’t just blindly interpreting your comps, they’re trying to make their own reusable systems with their own constraints and integrations and whosits and whatsits.
Without good visibility into the rationale behind a UI they end up guessing what was intended. When those guesses are wrong (and they will be wrong) you’ll have to pour through the screens and play a game of Where’s Waldo looking for inconsistencies in the implementation. The resulting small tweaks can undermine their systems, necessitating more rework than a few pixels here and there would indicate, which will then have to compete for dev resources against the new features that your product owner just added to the backlog. All of this is time consuming, frustrating, and expensive.
Traditionally, this is “solved” either by having the designer/product manager create a mountain of specs, sit and point at the developer’s screen while you both die a little inside
Or to have very long and very unproductive meetings where each element is scrutinized and story pointed and then still ends up needing rework.
I didn’t want that, so I turned to Webflow.
Getting Started
I started by building out the Sketch file, trying to make sure that the classes and logic I made would be reusable in the future. I couldn’t use the complex symbols and overrides that are common to visual tools, but I was able to use classes and class combinations to make my elements reusable instead; just as a developer would.
In other tools, simple concepts like margins and paddings have to be solved by a system of constraints or stacks or what have you. In CSS, those are table stakes (no pun intended). You lose the ability to easily make a small change to a single layer without fear of cascading implications, but gain the ability to change the margins, typography, dimensions, hover states, among many other things, for all instances of a class.
Is it easier to do it this way? No. Making rectangles will always be easier than making something real. And if you’ve not used Webflow before, you’ll have to mess around for a good while to understand how and why some things align in some ways and not in others. It’s not ever going to be a drag, drop, and done life.
But you can do things like this:
And this:
The second gif may look mundane, but let’s break down what’s happening:
- There is button
- With a minimum defined width
- Which is aligned with to the right edge of it’s parent
- With a hover state
- With constant margins
- That has sibling relations
- That pushes to a new line when that button grows too wide
- And characteristics that wrap the button text to a new line when it grows to be too wide for the parent container
- Which when resized grows it’s parent wrapper
- Which in turn makes the above automatically scrolling container smaller in relation to it.
All of these things, in a normal design tool, would have been a click, a drag, a move, a resize, a nudge. Not hard, not complicated, but seriously a time drag, especially when considering how many times this happens on a daily basis.
A designer’s daily lives involves lots and lots of resizing boxes and making nudges and small tweaks and checking alignments and duplicating elements and resizing boxes and making nudges and small tweaks and checking alignments and dupli… you get the picture.
Once the elements are made in Webflow, these types of changes are really easy to make. So yes, it’s a longer process to set up, but does it really take more time? I’d say no, especially when you take into account how much time documenting and explaining things like this normally take.
Also, when was the last time you tried to design with a bunch of different types of data, or even tried to use realistic data? It’s easy for a little while, but holy smokes does that take time to change once all of the static comps are made up.
Speaking of Dynamic Data
The Webflow CMS is great for dynamic websites, but for product design it’s perfect for creating a mock database. Before starting on a project in Webflow, I try to have a conversation with the dev team about the data structure. Once I know that, I map out a table in the CMS so that I can not only populate the designs with realistic data, but also be able to enforce conditional display logic in a way that they’d also be able to do so in production.
I’ve also started mapping those data fields to a tool called Mockaroo, and then importing what the csv it generates into my Webflow Collections.
Because of the way Webflow is built, I’m not just limited to a simple spreadsheet style mock database, but can make relationships between the data objects themselves.
You can set up those attributes to be arrays, short and long form text, images, integers, urls, booleans, etc. I set up a bunch of collections for this project and then linked used the Collection Lists to generate a list of users.
Once I had that built out, I was able to make each row navigate to a unique page for that entry in the Collection. No need to make it X number of times for all of those on that list, I configured the user page template once, and Webflow created all of the subpages for each CMS entry and populated those pages with data that is specific to that object instance. For specs, that’s not as necessary, but for realistic prototypes, that’s a huge win.
User Testing and Stakeholder Feedback
But I didn’t just use this for UI design and documentation purposes. I knew that as I was working, I’d be able to spit out a prototype that was pretty darn close to the real thing. I even made a fake Windows 10 UI to have the prototype sit inside, to simulate how it would actually function in the real world.
The original intent of this was for user testing, but it also made demos and showcasing the changes to stakeholders as easy as sharing a link.
Here’s a link to that project: http://agentexperience.webflow.io/
Also, as it’s a really living and breathing website, I was able to embed custom analytics scripts like Fullstory to see how people would play around with the site.
And the results?
Awesome. Really awesome.
Once the bug fixes were prioritized, I was able to go through this page with the dev and product leads and make requirements, get a more accurate scope of dev lift, and I even set up a wiki, of sorts, in Webflow to show the current state next to the future state, and reference Jira tickets. It was more effort to keep that part up to date, but it was awesome to be able to have the dev team inspect the design files and be able to see how it worked rather than how it looked.
After doing this, the bug fixes were spot on accurate and I got a better understanding for why things went wrong in the first place. Design and dev were able to sync up around this document and have more meaningful discussions about something that was already built.
I kept going with this system and totally abandoned any static files for that project. When we talked about adding new features, it was always designed in Webflow, and documented right along side.
I could have made a quicker prototype in other tools, I could have documented every pixel to the Nth degree, and I could have made an awesome design system in a normal design tool. If I had, I would have had multiple processes, in different locations, all of which would be out of date as soon as changes were made. My initial large time investment ended up saving documentation, design QA, and prototyping time. By doing it in Webflow, I was documenting the UI as I designed, getting a working prototype in out of it, and gaining a much better understanding of how the product needed to be built in order for the ideas to come to fruition.
It also works for Mobile Design
Having validated that Webflow improved results for a desktop product, I’ve also found success using it native apps, like this tricky feature in a calendar app I designed:
Why? Well… because I needed to show how elements should scale on multiple devices and demonstrate elements that were based on screen width and not pixels.
Also, I was working with developer teams who were on the other side of the world in a Windows environment. The prototype above was originally designed in Principle, but my only mechanism to handoff those design would have been to ask them to buy Principle licenses… then explain how to use the tool, let alone get specs from it, or to make a bunch of gifs and videos, all of which would take forever. Even if it didn’t, I wasn’t about to trust that it would come out close to how it was meant to.
I wanted them to be able to interact with the prototype, in any environment, and be able to have something to base our conversations off of. Also because this specific feature really needed to not have set pixel dimensions, I decided that redlines would only make things worse. Webflow allowed me to do that.
Play with it yourself: http://splitshift.webflow.io/
Micro interactions
Large scope ideas, though, are difficult to maintain in a team environment. At that company, I was a team of one, so it was easy to pick up where I’d left off and continue to work. Since leaving that role, I’ve begun using it more for micro-interactions and style guide definitions, creating single pages dedicated to a menu interaction, like this one:
Or a responsive progress indicator, like this one:
And the best part about these interactions is that they are the real deal. Try doing this with literally any other design deliverable:
The above example shows a hover state over dynamic text, with a button showing itself on hover, in-line, with it’s own unique hover behavior. This was a client project, and according to the dev the implementation was “wow that’s easy”. I didn’t spend a second doing design QA. Worth it.
Style Guides
It’s also great to create a common “style guide” to demonstrate some functionality. In a project I’m currently working on, I’ve found it very cumbersome to explain how large some touch-targets should be without a decent amount of back and forth. I had no ability to inspect the product, as it’s built in React Native.
To solve that, I made this pattern library, knowing full-well that the CSS and HTML will never be used in production. The goal was to get developers on different teams to reference the same elements in order to reduce rework and to help the design team to point to it when there are discrepancies:
I originally started working on how to explain this to the development team, but instead, I spent a half day to make this. As far as design is concerned, a picture is not worth 1000 words, it takes 1000 words to explain. Code speaks for itself, and does so in a much better job than I can.
Wrapping it all up
Every time I’ve used Webflow in a project, I’ve had developers or product managers tell me how much easier it is to implement. EVERY. TIME.
Just yesterday, I had a product manager come over to my desk and tell me how helpful it was to have it for a project on a tight deadline. His team had to rebuild the generated code all from scratch in React, and it was still a time saver. Paraphrasing: “It was great to have a real thing built out, so that we could see how it worked. Also, sharing the idea with stakeholders was way better than a taped-together prototype from another tool.”
This is not a traditional product design workflow. It might not make your designs flashier, it doesn’t export to Dribbble, it will confuse, befuddle, and cause you to have to change the way you design and think about your own UI in unexpected ways.
But it actually makes real things, and it’s the best way I’ve found to make real products.
I’m a Product Designer located in Nashville. Check out my work on my website. I occasionally tweet, but most of the time I spend time with my wife and my baby son. She’s a fantastic lifestyle blogger and he’s excellent at laughing at inanimate objects. Also, Hondo, our Bernese mountain dog is pretty dope too. Like I said at the get-go, links here are affiliate, yo.
