Let's take the gloves off.
No-code design tools have exploded on the scene and now allow designers to control the end product directly. Done well, this enables us to build a better product more quickly, with a smaller team.
The world of digital design is evolving at an amazing pace. In this tumultuous and unpredictable landscape, we may often find that even with highly skilled and fast-paced design & development teams, we end up with less efficient, lower quality products.
What is no-code design?
Fair question. From my perspective, what I call no-code design is simply this: A ‘no code needed’ process in which a designer or content administrator can go from nothing to a fully functional, high-fidelity end product without the intervention of a traditional development process. Sounds complicated, and yes, it used to be very complicated. But no more
In the before-time, the long-long-ago,
we would ingest requirements from our clients, then go and hunker down in our static design tools like Photoshop and Illustrator and design a mock-up. We relied on direct P2P communication alone to describe how things should move and behave. This was great until responsive design kicked down the door and ate everyone’s lunch.
So, we evolved into tools like Sketch and Figma that allowed us to do complex prototyping to simulate how the concept could and should behave in reality. They even gave us code snippets to pass to developers to take some of the pain away and help accelerate the end-to-end process.
Up until recently this was (actually it still is, but that’s another topic) going really well. Everyone was happy.
Designers gained some control over the things we obsess over like microinteractions & complex yet specific design systems. It allowed us the ability to present actionable prototypes that could be shared with clients, who themselves could then share with other stakeholders. Felt like a perfect world.
There’s only one problem. By definition, it’s all just smoke and mirrors.
Now don’t get me wrong…
There will always be a place for the traditional process, no matter how much the industry evolves and changes. But what if I could cut out a huge swath, and often most expensive aspect of project overhead? What if I could cut out development?
Let’s look at flaws in the traditional process:
- It can be fairly time consuming
- There are a lot of steps. There is a lot to consider, and those considerations need to be clearly understood by many people.
- It requires a comprehensive team.
- For any chance of success you need, at minimum, a project manager of some sort to intake and parse the requirements. You need a designer to lay out new concepts and ideas. You need a developer to take the designs and make them into an actual thing. You need a QA person to review everything and make sure it actually works. Take away one of these and you tread the line of failure. Unfortunately not all clients have the budget to support those roles.
- Designers rely on developers to read between the lines on interactions and behaviors.
- Does a button cross fade to a new color when hovered? Does a toggle switch have a nice slide to it? These are seemingly insignificant things, but when added together, they make a momentous difference. Kind of like the difference between frozen pizza you toss in the oven and a slice from Di Fara’s in Brooklyn. Both have the obvious elements of pizza, even the same exact ingredients,, but one is far better because it is executed better.
Let’s take a chance on no-code design and I’ll shed some light on how it can help solve some of these problems.
The problem no-code design really solves is that it puts the end product in the designers hands. It cuts out the middleman, which in turn slashes the budget and time requirements for a project.
No more long zoom calls with developers saying things like “can you make this fade on load?” or even when you get past that, maybe it fades on too fast. Or a button should have a fun transition when hovered, or tapped.
It puts the power in the designers hands to control this. It allows the designer to see the end-product directly because that’s what it is.
We can close complex and convoluted feedback loops on how elements should be visually presented. It forces designers to think on the fourth plane.
It takes them just far enough outside of their comfort zones to become more innovative, but also helps battle-harden them and make them a better communicator when we need to revert back to the traditional development process.
It bridges the gap between developers and designers both on a capability level, but also on a language and communication level.
It helps make us one. In harmony together.
What a designer views in their preview window is what will actually exist.
The value of this concept is severely underrated. Remembering what we read at the beginning of this article, previously, we could only simulate this.
Now we can realize it.
Let’s take a second to build a list of what this means for us as designers.
- Popular tools like Elementor, Builder.io, and Webflow offer a design environment I am familiar with.
- I have the ability to create complex, layered designs just as I would in Figma or Sketch or whatever.
- These best in class no-code design tools offer pre-built tools that allow me to add text, images, animations, buttons, and any and all of the wonderful components I need to create beautiful web experiences without having to reinvent the wheel each time.
- I can control the nuances of a design
- Should an image fade on when the user scrolls? Should a transition animation happen when I click something?
- I can set up my design system directly and deliberately in the platform.
- I set up my type, image, and global styles in one place and they are by default reused throughout the document.
- Where I once had to rely on the back and forth relationship with a developer to bring these nuances to life, now I control it all with ease.
Cool. How does this help me?
Well for starters, my team can be smaller.
Smaller teams mean less overhead. Less overhead means more profit.
While it’s never a bad idea to have a developer to bump ideas off of, it’s no longer required, which before now was basically unheard of.
The thing I build in Elementor or Webflow is what will actually exist in reality. Now, I can be a team of one. My agency can take on those smaller projects and bang them out at the same, and generally higher, quality as enterprise projects.
Also, my QA time is greatly reduced.
By employing in-browser design, I am forced to QA as I design because my preview is actually real. My time-to-live can be vastly cut. And if my time-to-live is cut, the profit margins for my agency can be higher.
Reasons to make it work for you:
- Empower yourself (or your design team) to take direct control of micro-interactions
- Reduce project overhead costs by relying on a smaller team
- Let developers focus on big challenges like back-end infrastructure
- Cut-time-to-live from months to weeks, or even days.
Sounds amazing, but it’s not all sunshine and rainbows.
I’d avocate this for this to be used on many projects, but it’s clearly not the right choice for everything. The traditional design process still holds king for large scale ecommerce and content sites.
The flaw exposed here is, as a designer but also site owner, new requirements will fall on me to realize, and they all may not be easy or even feasible at first glance.
As a project manager, I may get frustrated with my design team if they are not available to make changes.
In my experience, many if not all challenges can be bridged, but it requires designers to think on a higher plane.
When making the choice for in-browser design, we need to think for extensibility and growth as considerations beyond pure design..
We need to anticipate where the project will evolve. To truly be successful, we need to adopt new skills that we can leverage to grow our products.
In-browser design is right there standing next to tools that empower this if you play your cards right
Those flaws can be blessings in disguise.
If we choose to embrace in-browser design as a core methodology, we have to have a willingness to evolve.
We have to understand that as time marches on and technology improves, the design / developer roles will continue to merge in some areas, and become more distant in others.
Embracing and nurturing this is the future.
An amazing example of pairing the magic of no-code design, specifically for designers, with traditional design processes is that we can net-out at a bespoke and finely crafted toolset that any content admin or site editor can work with.
I love tools like builder.io and React Bricks for situations like this. But that’s a tale for another day…
Are you willing to take this on?
We’re all here together trying to navigate the boisterous climate rising these waters.
My goal is to understand the problems we all face in our fast-paced design & development teams so we can together end up with more efficient, higher quality products. In-browser tools offer us a chance to control the end product directly, enabling us to build a better product more quickly, with a smaller team that will, with perseverance and a bit of luck, result in happier clients.
How do you feel about this new world?
