"It’s easier than ever to build software. Now, in just a few hours, you can create something that used to take specialized skills and countless days. This is all because of the "no code" tools that let you do so much without writing a single line of code."
Now that we’ve positioned the “no code” movement in its historical context, it’s time to dig into the why of ditching code for website design, development, and marketing.
Initial prototypes of a digital product often don’t need anywhere near the engineering investment as their initial launch counterparts will. Early on, something as simple as a series of well-designed images (like an InVision prototype) might be enough to communicate the core idea to potential investors, early adopters, and future team members.
As the idea evolves, more and more fidelity will be required — but even then, tools like Webflow, Bubble, Glide, and Voiceflow can provide incredibly robust experiences that could be more than enough to pique interest and validate hypotheses. And once you’re ready to start exposing your idea to the public, Webflow, Bubble, and Carrd make for beautiful, highly efficient tools for the landing pages you’ll need to communicate your core value proposition and other benefits.
Everyone who’s ever managed a project, regardless of discipline, knows that the more people you need work from, the more difficult the logistics of on-time and on-budget delivery get.
The traditional digital delivery process relies on at least:
And for more complex deliverables, engineers may be needed as well. Plus, each of the three disciplines above may well involve multiple practitioners, so the above list could well look more like:
And we’re not even addressing research, which should really precede content. We’re also leaving out all the stakeholders and subject matter experts you might need to involve to ensure that content and design are delivering the right messaging, visuals, and overall experience!
This isn’t to say that projects work better without developer or engineer help. Or that they’re in any way better without those professionals. But by freeing them from having to work on marketing assets like new landing pages, blog builds, etc., you give them more time to work on other, more complex projects. Projects where their value is truly realized.
By freeing your marketing team from dependencies, you also make the path to launch faster and easier. Instead of pulling a dev from product work, your designer can implement and hook up any required forms. Instead of pulling an engineer to create and connect a database to your dynamic content pages, your content strategist can handle the modeling and structure. And your paid marketing team can launch new ad campaigns backed by custom landing pages they built themselves. The fact that smaller teams can move faster than larger ones isn’t a wonder — it’s an intrinsic truth.
To be clear, this isn’t to say that you can skip important steps like research, subject matter expert interviews, or stakeholder reviews. These steps may slow down the process, but they’re indispensable, and they can often be done in parallel with other work.
Developers and engineers are typically — by dint of their extensive training, key role in product development, and relative rarity — more expensive than your average marketing team member. Fair or not, it’s a reality. So any time you can remove a developer or engineer’s time from the project equation, you’re not only saving time, you’re saving precious funds.
With lowered costs and dependencies comes greater freedom to take risks. To try things that might not ultimately work — or scale. But even failure represents a valuable learning opportunity.
For example, the Webflow team recently began experimenting with various new-user onboarding formats. With a focus on learning over winning, we were able to try solutions that we hypothesized wouldn’t work — but even if they didn’t, we’d at least know that approach X wouldn’t work. Because we’d actually given it a shot.
And you know what? Our initial test did work. In spite of our hypotheses, which were informed by both quantitative user data and qualitative user interview findings, both versions of what we assumed would be failed tests provided statistically significant improvements in active time in the Designer, the key metric we were aiming to move the needle on.
You really do never really know until you try. And now that we’ve tried, we know.
Up till the present moment, the design process for digital products and websites has followed a pretty familiar path:
Someone — a designer, a product manager, a content creator — has an idea. They begin to flesh the idea out in the format that makes the most sense for them, be it a Dropbox Paper doc, a piece of real paper, or a design tool like Sketch. The creator likely iterates there for a while, then reaches a threshold of confidence in their idea: the point where they’re ready to share it and get feedback from others.
This is where the most popular design tools begin to lose their relevance (at least, up til late 2018). Because they’re largely static: you can share them with others, but they can’t really interact with them in any meaningful way.
Of course, the makers of these design tools have realized this hard limitation, and began to build tools like Sketch Prototyping, Adobe XD, and InVision to bring those static mockups to some form of life.
But for almost all of the above tools, the prototype is itself a disposable artifact. People can interact with it and provide feedback, but that’s where its usability ends, because it’s really just a series of images cunningly linked together to fake a real, interactive experience. They have no usable output beyond the prototype, collaborate, and iterate stage.
It’s here, where the rubber meets the road, that design tools have historically ceased to be of much utility. Developers and engineers pick up where the designers leave off, working largely to translate the static designs they were handed into real, functional code.
This is also where most marketing teams’ and makers’ start feeling their dependencies. The new site, blog, or landing page leaves their hands entirely and becomes subject to unpredictable shifts in the larger product roadmap, where dev/eng “resources” may suddenly be reassigned, run into tech debt issues, or other bugs. Marketers and makers are left to sit and wait (and move on to the next idea).
This is exactly where “no code” tools — and in particular, Webflow — really come into their own. With the lowered barrier to entry these tools represent, marketers and makers can ditch the dependencies and get something out into the wild that one precious day, week, or month earlier — and start gathering feedback, iterating, and learning faster.
All of that also means that static “design” tools — in the broadest sense — become less and less useful. Which means fewer disposable artifacts — and lowered software costs.
It’s no secret that Silicon Valley has a bit of a diversity problem. The vast majority of the startups that have gained real traction are therefore designed to meet the needs and overcome the “challenges” of people who are mostly like their builders.
That is: white, male, middle to upper class, tech-oriented, etc.
By diversifying the array of people capable of building and launching digital products, no code tools have the potential to also diversify the range of products being built and the speed with which they can come to market.
To date, the tech landscape has been dominated by those with computer science degrees. Engineers. People who are trained to approach and overcome problems in a particular way. People who value efficiency, data, analysis.
Those with backgrounds in the humanities tend to think of problems differently. Efficiency is rarely much of a concern. Quality, affect, and experience tend to dominate their thinking.
So you have to wonder: what would a comp lit major build, if they were to build software? How would a philosopher, or environmental lawyer, tackle technological challenges?
For the record, I realize that the above includes many generalizations. Webflow's CEO, Vlad Magdalin, trained as a 3D animator before switching over to engineering. And it’s hardly as if there are no non-white makers out there.
But we need more. More diversity of background, viewpoint, and opinion. Because the more diverse our cast of makers becomes, the more diverse the solutions available, and the more holistically those solutions will meet contemporary problems.