1

It’s OK to code, it’s OK to no-code, but there’s a cost to both

 1 year ago
source link: https://uxdesign.cc/its-ok-to-code-it-s-ok-to-no-code-but-there-s-a-cost-to-both-5808ee12e657
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

It’s OK to code, it’s OK to no-code, but there’s a cost to both

a keyboard, code bracket icon and paint palette representing design tools

Preface — This post may appear as an overly critical review of no-code tools, but it’s not.The goal is to look at coding and no-coding through different lenses: a designer, a developer and a product founder. This article explores product end goals and output.

The no-code movement is growing. New platforms embracing no-code and low-code are popping up all over and before you know it design Twitter is yet again abuzz with “code is dead, no-code is the future” tweets. Are these designers correct? Is coding dead?

What if I told you there was once a dynamic piece of software that was so popular that it powered nearly one-third of all websites on the internet and was the backbone of most videos online? It was a design tool, a coding tool, an animation tool, and even a game engine. It was one of the most in-demand software skills to have in the early 2000s, and now it’s dead. I’m talking about (Macromedia) Adobe Flash.

I imagine there are a handful of young designers who have never heard of Flash. It’s been dead for more than a decade, and in 2021 Adobe discontinued support for good. This is what’s called a product life cycle.

a product lifecycle chart showing launch to decline

Product life cycle

With countless tools put out to pasture, Flash may seem like just another defunct relic of the past, but this example is special. Flash dominated and changed websites in the 2000s, and it’s a significant reminder that no matter how popular a tool is, none are exempt from extinction.

So what does Flash have to do with no-code tools? I caution the no-code disciples to be nimble when hitching their entire career to one piece of software. Flash had once been a boasted skill on many resumes, my own among them. This single point of failure is a pitfall many designers often forget about.

Sketch is owed a lot of respect. Before Sketch, most people used Photoshop for designing their UIs. Sketch was the first to understand the need for a UI focused design tool. For a long time it owned the entire UI design market. Then Figma came along, becoming the top choice for most designers. Flinto was the king of animation and interaction design, until Principle came along and ate their lunch. But with no-code tools, nobody can top Webflow! Unless you search Framer on Twitter and, well, it appears Webflow has some serious competition. I think you see where I’m going with this. Software launches, gains popularity, evolves and often dies. I’m not saying any of the aforementioned tools are dead (yet), but for many of them their popularity is declining.

Practically speaking, it’s not too difficult to migrate between similar tools like Sketch and Figma, for example. Migrating tools when you’re dealing with complex code and functionality becomes far more challenging. Redesigning a UI in Figma isn’t the same as rebuilding a platform in a new no-code tool.

While it appears that Webflow, specifically, is going to be around for a while, let’s remember that not long ago they almost went bankrupt. If your company’s bottom line is tied to a single point of failure, well, that’s a precarious space to operate in. If your no-code tool goes away, you’d have to rebuild it from scratch, hoping that the new tool you choose supports the features you need.

I recently read a Twitter thread from a founder of a start-up. He was mentioning how he’s switching from Webflow to Framer. He discussed how he has to rebuild his entire site on that new platform, listing all the little changes he’ll have to make because the new platform doesn’t have all of the same features as the old one. Things as granular as having to change the hover states of his buttons. This kind of thing happens all the time. Rebuilding products and eliminating aspects of them based on no-code features, or lack thereof.

Two huge components of a successful product are the ability to scale it and expand upon its feature offerings. Let’s use Instagram as an example. Pretend for a moment that Instagram was created with a no-code tool. People love it! Posting and sharing images catches on and before you know it you’ve got millions of users. You realize that you can lower your operating costs by migrating to AWS, except your no-code tool is only licensed with their web services and you’re subject to whatever they decide to charge. Oh well.

Maybe you’re less worried about operating costs and more interested in feature iteration. You want to create a new short-form video feature since TikTok has become so popular and your users are begging for video in your app. You open your no-code platform and, uh oh, no video features are available yet.

Then you begin receiving bug reports. The app crashes when your users disconnect from wifi. How do you fix this without coding? You can issue a support ticket to your no-code tool and hope they can address the bug before your users delete your app.

You deploy an email survey to your users. A customer with a visual impairment lets you know her screen reader can’t properly scan your app. How do you fix this? Another support ticket to your no-code platform and cross your fingers they fix the issue before you lose another customer.

Lastly, perhaps you decide to rebuild your app outside of the no-code tool so that you can have full freedom to address all the challenges mentioned above. You have no code repository, no place for your new engineers to begin. No version control or standardized development.

These types of examples can go on forever.

a mosaic of icons representing software challenges like security, bug fixes, design and authentication

Don’t get me wrong, no-code platforms have some amazing capabilities. It’s no secret that no-code tools are powerful and have empowered designers to move their ambitions from static mock-ups to working products and websites. No-code and low-code platforms are only going to continue to grow and get better. But there is a widespread misunderstanding, primarily from designers, believing all output is equal and once you’ve shipped, you’re good-to-go. This erroneous perception that a website created by Webflow or Framer is the same as a website created with React, for example, is significant. I totally get the appeal of no-code! I’m first and foremost a product designer myself. It feels like magic after dragging a component onto a screen, hitting a publish button and voila, you’ve got a website. What’s absent is the understanding of where you go from there should your website need to grow and evolve.

I often use a browser extension called Hoverify. This extension lets you deep dive into all aspects of a website’s code, including a look at the tech stack which comprises it. Think of it like if a designer redesigned right-click “inspect” for browsers. I run this extension all the time and have found some beautiful sites designed with no-code tools like Webflow and Framer. Let me be clear, these websites are beautiful and the designers who created them wouldn’t have been able to do so without no-code platforms.

These sites are more often niche static marketing sites and freelancer portfolios, two areas where no-code tools really thrive. What you rarely (if at all) see is an enterprise level product created with a no-code tool.

Netflix, Airbnb, Asana, Trello, Instagram, Facebook, Dropbox, NY Times, Uber, Code Academy, Reddit, Atlassian, Sound Cloud and so many other behemoth platforms are built with React, for example. There are all varieties of frameworks out there, but what is common among these platforms is they cannot operate using a no-code tool. Not right now at least.

Not long ago I noticed that a product I use often, Craft.do, rebuilt their site moving off of Webflow and instead using Tailwind (CSS framework). I was curious about this so I emailed their product team. I was delighted when they wrote me back with an explanation. To respect their privacy I won’t disclose the details of why they moved away from Webflow, but the fact that they did move away from it underscores my point. They launched their product with a beautiful no-code website and as their product grew, they needed to shift to traditional development.

There’s a fundamental misunderstanding by many designers about the output of a product or website and how we arrive at that output. As designers, we can get hyper focused on a beautiful website with scrolling animations and complex layouts, all done without writing one single line of code. Of course this is appealing! What designers often miss is what happens when you need to scale your product. When you need to iterate your product. When you need to fix your product.

What if the business is asking you to do something your no-code tool cannot do? Change from a traditional CMS to a headless CMS. Change your database, change your CRM, or change your analytics tool. What about adding a new feature that the no-code tool doesn’t have the capability of adding? What about staging environments, quality checking and release processes? Maybe your tool has the features maybe it doesn’t.

Let’s imagine for a moment you’re no-code pro and landed a job on a new product team. Your new product manager has some updates for you: Beautiful website you made! Can it use Salesforce as our CRM? Can it work with Algolia for our search? Can you add ARIA attributes to the elements? Can we add Apple login as an option? Oh and we have a proprietary CMS we’ll need to use for our content team. And the data engineering team want to test a new feature to just a segment of our users within XYZ group.

Many designers believe that no-code tools will end the need for coders and to some extent they’re actually right, just not in the way they’re imagining. Sure, products like Webflow have eliminated the need for costly developers for niche groups like agencies & freelancers, and independent online retailers. Even no-code platform, Framer, unapologetically lists their platform’s use cases as “agencies, marketing, start-ups, and freelancers.” Webflow has grown its feature set with the ability to create logic-based web products which appeals beyond Framer’s use cases, however, leveraging these features still means you’re handcuffed to their ecosystem.

It wasn’t long ago where a search for “webflow” jobs on Zip Recruiter would yield zero results. Now, however, you can find quite a few. But if you search for “web developer” jobs, well, there’s a bit of a higher demand. This is why the tools are so popular with agencies and freelancers, where there are little to no need for support after you hand off the website to a client.

zip recruiter searches for webflow jobs with 179 results and developer jobs with 223 thousand results

Actual numbers from Zip Recruiter job search for webflow vs web developer jobs

It may appear as if that comparison is being facetious, but it’s meant to show there’s growth in the no-code world. No-code platforms have helped small businesses deploy their own stores, helped marketing agencies launch incredibly beautiful websites for new apps and retails products. These platforms have helped startups test their product ideas inexpensively without the cost of software engineers. Designers can now break out of the static design space and into the working software space. This is all thanks to the advancements in no-code platforms. Sure, no-code can’t create a Dropbox clone, but that’s also not what’s being asked of it at this moment in technology.

I mentioned in the preface that this is an equal part discussion of creating with both no-code as well as code. Using traditional methods of creating a product or website through coding has strengths and weaknesses just like their no-code counterpart.

Remember when I talked about Flash earlier in this post? Well, Flash also used a specific language called ActionScript to create its websites. How in-demand is that skill set today? Uh…

zip recruiter search results showing zero action script jobs available

Actual numbers from Zip Recruiter job search for actionscript

Traditional methods of software development are not exempt from failure points of their own. However, there are ways to mitigate this risk. For example, JavaScript was create in 1995, nearly 28 years ago, and is still the backbone of the most powerful frameworks fueling the web including most no-code platforms themselves. Of course, JS has evolved in all sorts of ways, but understanding JS means you can work with a much larger variety of tech stacks.

a tweet highlighting coders have further reach into product creation outside of no code tools

I tweeted a while ago about how designers perceive code vs developers, albeit with a clumsy analogy. What I meant by this is knowing how to use Webflow, Framer or Bubble (to name a few) means, well, you know how to use Webflow, Framer and Bubble. You can apply for one of the 179 Webflow jobs available on Zip Recruiter.

Knowing how to code with JavaScript, on the other hand, means knowing how to leverage React, React Native, Vue, Nextjs, and you can apply for essentially any of the 223,901 front-end developer jobs posted on Zip Recruiter.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK