Specialization by separating design and development between different people ensures the best possible result. Using this approach the designer creates the UI for specific breakpoints using static data and a WYSIWYG tool that doesn't require writing any code or markup. Without having to think about the design the developer then translates the design into code, connects it to the data and ensures that it looks as designed on all devices and viewports.

But, what if there is no designer? In this post we will look at how a developer can approach the process in order to ensure the result will look as if it were separately designed. Before that the history as well as the current state of tools is discussed.

For a long time Photoshop served as the go-to design tool for websites. It sold at a notoriously high price and was primarly targeted to photographers which needed to edit their photos. Together with Illustrator which focused on vector graphics it offered everything the designer needed. For beginners the product was only affordable thanks to a 30 day trial period. Photoshop offered any feature related to image editing one could think of - yet - web designers only had to know a few of those features to design a website.

The high-price, the focus on image editing for photographers as well as missing support for vector based graphics all paved the way for competitor tools specific to web design. As expected, Sketch came along. Sketch had none of the issues of Photoshop and was readily adopted by the web design community. By that time pretty much any designer was using macOS so it wasn't an issue that Sketch was only available for the Mac on the desktop.

While pretty much any designer had a Mac, their counterparts in management and development often didn't and therefore had no way to look at the design. All of this was about to change in 2015 as Figma a design tool running in the browser was introduced. Running a design tool in the browser became possible thanks to Sketch proving that most of the heavy image editing algorithms included in Photoshop weren't actually necessary to design websites. This and the fact that the browser as a platform had considerably improved to make designing websites possible. Figma doesn't require the user to download an application and therefore makes sharing the design with others very easy and convenient. Unlike Sketch, it also offered access to a lot of features free of charge which lead to the tool becoming very popular and almost irresistable for any designer. One of the founders of Figma was Evan Wallace known in the web developer community as the creator of esbuild.

Like many, I've created my first websites using Microsoft Frontpage as well as Macromedia Dreamweaver. They offered a way of creating websites without code using a WYSIWYG approach. While creating websites using this approach was already used two decades ago it is still used today. Todays, no-code tools have gone through a similar transformation as the design tools. Popular examples are webflow, framer and wix.com. Unlike the design tools, the differences between these no-code tools can be significant and it's worth checking a few of them out.

Compared to regular development involving programming these types of tools have always had their fair amount of market share and will continue to do so in the future. It's unlikely that they will eat away at the coding approach much more then they did in the past. Depending on the project these tools are either suited to do the job or they simply aren't. For some cases the no-code approach works just fine while in other cases coding is still required. Much like the choice of a framework for a mobile application it all depends on the context. Things like a personal website or a restaurant page can be created by anyone using these tools and the results will usually look amazing. Thanks to themes and various common components something can be created with a few clicks that would otherwise take a seasoned developer hours to create using a programming based approach.

Can't these tools keep up with regular development? While these tools even offer the integration of a CMS or dynamic data from an API they will never be able to offer as much and be as flexible as all the open source tools offered through npm using the decentralized open source approach. Integrating a plugin into a no-code tool requires much more effort than offering a JavaScript interface through npm. No-code tools also have to make a choice which plugins and features to provide whereas the open source ecosystem offers a nearly unlimited supply of tools, plugins and frameworks.

While some developers especially the ones leaning towards the backend are notoriously bad and uninterested in design it's differnt with UI or frontend developers which often already have some experience with design and no-code tools.

Creating a good design for somebody specialized outside the UI can be challenging. In this case the best way is to resort to using a UI framework that already comes with a certain design and can be themed if necessary. While this results in a non-unique design it's often the best approach as learning how to create a UI would take a lot of time and for some the UI might not be as exciting.

While most web developers already have some experience with design tools they are often way behind designers as these tools often have a significant learning curve in order to achieve mastery. The key to success for a frontend developer is to double down on their strengths while taking the same shortcuts as the designer takes. No-code tools as compared to design tools often require additional input in order to get over these shortcuts usually taken.

The design is for one viewport only. There is no such thing as a responsive design. When an additional breakpoint or viewport is designed the existing design will be copied and adapted to fit that breakpoint. Unlike with media queries in CSS there is no connection between the same elements as they are simply duplicated before being changed.

The design is only viewed through one engine. When creating a website one often has to make sure that anything works on different browsers. Design tools offer an encapsulated environment where the result will always look the same.

When designing implementation is of no concern. To implement a website in a reasonable amount of time developers often use existing packages that provide some functionality and only have to be configured and matched with the design. Common examples are a slider or a popup. When designing one doesn't have to worry about whether there is a package available that will support the design. If there isn't, the developers can always recreate the functionality from scratch. Using this approach will avoid much of the research that a developer would otherwise spend in the design phase. As a rule of thumb anything that can be found in the wild already implemented can be implemented by a developer. Truly original ideas (which are rare) are somewhat likely to fail in a later stage as their implemenation is simply not feasible.

The design isn't connected to any real data. Instead, as text there is often some fill text used. This also means that most edge cases like big numbers, lots of text or invalid inputs don't have to be considered during the design stage.

The design usually doesn't have to be maintained and therefore doesn't need to be made generic. When a design is implemented a part like the header isn't just copied over to a next page but a generic header component is reused. Making a component reusable instead of just copying adds additional overhead which isn't necessary for the design stage.

Luckily, most of the sortcuts taken by designers can also be taken as a developer. This way one can fully concentrate on the design without getting carried away by implementation details or watching tons of design tool tutorials first.

To do this first gather some inspiration and get a basic idea in your head how the design should look like, possibly jotting down some sketches on a paper. Just like for a designer it's very important to know all the requirements of the application before starting. Once you have a picture in your mind how the application should look like it's time to get right back into the developer comfort zone and set up a fresh site with your favorite framework.

In order to be able to work on the design and it's aspects make sure to only create the main viewport. Avoid setting up or using anything remotely related to breakpoints or responsive design. Depending on the target audience setup either the desktop or mobile viewport. Later, using a mobile-first or desktop-first approach, the existing implementation can be adapted to cover more breakpoints.

Needless to say, it's also not necessary to ensure that the design looks good in every browser during the design stage. CSS snippets or styles taken from existing applications can be used without the need to first check on caniuse whether all the properties are supported.

An advantage compared to design tools is that plugins can be inserted and usually come with some good looking styles out of the box. When something is customized it's already guaranteed that it works and one isn't tempted to make hard to implement design choices. Depending on the context this can really save a lot of time and headaches when compared to a specialized approach.

When a developer is in the design stage it's not necessary to connect any actual data. Simple placeholder text can be used just as done by a designer. Even on the frontend it's quite easy to separate the data layer and business logic from the UI so that this whole part can be added later. Having a finished design in place will also make it easier to architect the backend and can answer a lot of questions. Edge cases like long strings or small numbers can be postphoned during the design stage and taken care of during the implementation stage.

It's possible to just implement the UI design in HTML and CSS and then later during the implementation stage move over to a framework. When using a framework the creation of generic components split up into different files already during the design stage can save a lot of copy paste effort and will provide a base to work on later. Any developer will be used to create components and it doesn't really add any overhead.

It's important to avoid creating vector graphics by hand. To create elaborate shapes and icons a WYSIWYG editor is much better. Create the shapes there in isolation and export them as SVG. Usually, the exported files will be small and the source code can directly be embedded as JSX. In this way the shape becomes a component that can easily be customized and reused.

const Arrow = ({ size = 20, color = 'black' }) => {
  return (
    <svg
      width={size}
      height={size}
      viewBox="0 0 100 100"
      xmlns="http://www.w3.org/2000/svg"
    >
      <path
        d="M4 92.8528C4 95.0619 5.79086 96.8528 8 96.8528L44 96.8528C46.2091 96.8528 48 95.0619 48 92.8528C48 90.6436 46.2091 88.8528 44 88.8528L12 88.8528L12 56.8528C12 54.6436 10.2091 52.8528 8 52.8528C5.79086 52.8528 4 54.6436 4 56.8528L4 92.8528ZM96.8528 7.99996C96.8528 5.79083 95.062 3.99996 92.8528 3.99996L56.8528 3.99997C54.6437 3.99997 52.8528 5.79083 52.8528 7.99997C52.8528 10.2091 54.6437 12 56.8528 12L88.8528 12L88.8528 44C88.8528 46.2091 90.6437 48 92.8528 48C95.062 48 96.8528 46.2091 96.8528 44L96.8528 7.99996ZM10.8284 95.6812L95.6812 10.8284L90.0244 5.17154L5.17157 90.0244L10.8284 95.6812Z"
        fill={color}
      />
    </svg>
  )
}

export default () => (
  <div style={{ fontFamily: 'sans-serif' }}>
    <p>Reusable Vector-Based Component</p>
    <div style={{display: 'flex', alignItems: 'center', gap: 20}}>
      <Arrow />
      <Arrow color="red" />
      <Arrow size={40} />
      <Arrow size={10} color="#0000FF" />
    </div>
  </div>
)

The above shows a generic arrow icon component that was exported from a design tool and is now embedded as a JSX component into the JavaScript bundle where it can be reused in various sizes and colors.

As we saw pretty much every shortcut designers use to create a representation of the end result can also be taken as a developer. While this approach isn't WYSIWYG any changes and tweaks can still quickly be previewed in the browser to ensure the design looks good. The learning curve to get the hang of a design tool disappears other things like gathering inspiration, knowledge of design trends and theory are still necessary. On the other hand, this approach is more economical as there is no throw away intermediate product. Once the UI produced during the design stage looks good the implementation continues by refining the existing artifact.