Is Wireframing and Figma Design Still Necessary for No-Code Websites?

Design & UX
1

Howdy y’all! :wave: I’m new to web design, working mainly with no-code platforms like Wix and Webflow. I’ve run into a question that I’d love some input on:

Since no-code speeds up the development process, projects usually cost less than traditional builds. But, as many of you might know, clients often want to “see” the design before diving into development—which usually means extra time spent on wireframes or Figma designs.

So here’s my question: Are wireframes and Figma design still essential when building with no-code platforms? And if clients insist on seeing visuals beforehand, is there a way to avoid full mockups or maybe use simpler alternatives?

Any advice would be awesome! :pray: Thanks!

2

You may or may not find the following helpful…
index.html

<!DOCTYPE HTML>
<html lang="en">
<head>

<meta charset="utf-8">
<meta name="viewport" content="width=device-width,height=device-height,initial-scale=1">
<meta name="keywords" content="content, alt-text, semantically, headings, external stylesheet">
<meta name="description" content="How to make a web page">

<title>How to make a web page</title>

<link rel="stylesheet" href="screen.css" media="screen">-
</head>
<body>

<h1>How to make a web page</h1>

 <ol>
  <li>
   <p>
    Start out with your content or a reasonable facsimile of future content - ALL OF IT - in a flat text editor 
    and arrange it as if HTML and CSS don't even exist!. Don't worry about formatting it, just type in your 
    content with headings as if you were writing a flat professional document for text-only printing, with the 
    alt-text for any content images representing said images.
   </p>
  </li>

  <li>
   <p>
    Markup that content semantically, saying what things ARE ( paragraphs, short lists of bullet points ) and 
    enhancing the logical document structure with numbered headings and horizontal rules.
   </p>
   <p>
    Remember unless you use HTML 5's idiotic, pointlessly redundant structural tags, your H1 is THE heading ( singular ) 
    on your SITE (singular) that everything on every page is a subsection of. Same as how the title of a newspaper or 
    book is at the top of every page or fold-pair. An H2 or HR indicates the start of major content subsections with 
    the first H2 indicating the start of your main content area. H3 mean the start of a subsection of the H2 preceding 
    it. H4 means the start of a subsection of the H3 preceding it, care to guess what H5 and H6 mean? They have 
    structural meanings which is why going "up" in number you don't skip around willy-nilly, why pairing a H1 + H2 for 
    title and tag line is ignorant nonsense, and they sure as hell don't mean "fonts in different weights and sizes" nor 
    does HR mean "draw a line across the screen". Those are simply their default appearance for screen media, which is 
    again NOT what HTML is even for in the first damned place.
   </p>
   <p>
    As this is the semantics stage, you likely shouldn't be adding DIV or SPAN since they are semantically neutral 
    existing just as hooks for saying "this might receive style" without saying what that style actually is. It also 
    means no classes or ID's yet.
   </p>
   <p>
    Basically on this step, if you choose any of your HTML tags based on what they look like instead of what they mean 
    grammatically, structurally, and semantically, you're doing it ALL WRONG.
   </p>
  </li>

  <li>
   <p>
    Using an external stylesheet bend the markup to your will to create the first (of many) screen media layouts. This 
    means the &lt;link&gt; should at LEAST have media="screen" on it since your screen layout means dick to print, aural/speech, 
    tty, etc, etc. This is why if you see a &lt;link rel="stylesheet"&gt; that lacks a media="" attribute, or sets media="all" 
    what you are likely - as I say a lot - looking at developer ignorance, incompetence, and/or ineptitude!
   </p>
   <p>
    The first layout for screen I suggest creating is the legacy desktop. A LOT of people will say "mobile first" but that 
    is utterly backward thinking. Any mobile devices we care about supporting can be targeted and customized with media 
    queries, whilst legacy desktop cannot... so why the blue blazes would you start with what you can customize, since then 
    how does one even target non-media query capable devices? Makes no sense.
   </p>
   <p>
    At this point you can also add any presentational images in the CSS, since images that are part of the template have 
    ZERO business in your HTML as content. Thankfully the need for such images has dwindled as CSS has taken over.
   </p>
  </li>

  <li>
   <p>
    Once that legacy screen layout is defined, narrow the screen width until the layout breaks. Figure out how many EM that 
    is, and write your media queries to adjust the layout stripping off columns, adjusting paddings, and so forth. That's 
    your breakpoint.
   </p>
  </li>

  <li>
   <p>
    Lather, rinse, repeat step 3 until you're down as small as you think you'd need to support. Whist there are 192px wide 
    devices, they have really disappeared from the mainstream so I treat a 256px display size ( 16em if you're on standard 
    metric font-size ) as the minimum width to support. 
   </p>
  </li>

  <li>
   <p>
    Then and only then once you have a fully working responsive page, do you have any business even thinking about enhancing it further with JavaScript. If you needed JavaScript before this point, you've screwed up. If the layout or even basic page functionality doesn't gracefully degrade when JavaScript is blocked, unavailable, etc, then you've done it all wrong.
   </p>
  </li>
  <li>
   Author - <a href="https://deathshadow.medium.com/">Jason M. Knight</a>
  </li>
 </ol>

</body>
</html>

screen.css

body {
    margin: 1em;
    background-color: #ddd;
    font: 100% / 162%  sans-serif;
 }
h1 {
    font-size: 1.25em;
    color: #555;
    text-align: center;
    text-transform: capitalize;
    letter-spacing: 1px;
 }
ol {
    max-width: 40em;
    padding: 1em 2.5em;
    margin: auto;
    border: 1px solid #999;
    border-radius: 0.75em;
    background-color: #fff;
    box-shadow: 0.4em 0.4em 0.4em rgba( 0,0,0,0.3);
 }
li:last-of-type {
    list-style: none;
    font-style: oblique;
 }
a {
    font-style: normal;
    font-weight: bold;
    color: #000;
 }

See this page here…

https://codepen.io/Snady_Leiby/full/KKOBJvo

…and the author’s other articles here…

https://deathshadow.medium.com/

4

Yes, wireframing and designing in Figma (or a similar tool) can still be very helpful for no-code websites. Even though no-code platforms make building websites easier, wireframes and design prototypes allow you to plan layouts, structure, and user experience before diving into the build. They also help ensure alignment on design decisions and reduce the need for major changes later. Using Figma can be especially useful if you’re collaborating with others, as it provides a clear visual guide for how the final website should look and function.

1 Like
5

Yes, wireframes and Figma designs can still be useful for clarity in no-code projects, but you can use simpler alternatives like low-fidelity wireframes or mood boards to give clients a visual idea without creating full mockups. This saves time while still aligning on design expectations.

1 Like
6

Thank you all for your suggestions. I have one more question. If I use Figma to create a wireframe, is there any way to convert that design on Figma to a no-code platform such as WIX or Weblfow to save time? (I’m not a Figma expert).