What's in the future for web design and UI development?
For the last decade or so, many relied on hand coding UIs. Web design tools improved a lot, but what about development? Is it time to change the status quo?
I've been working as a frontend engineer for over 11 years now. I still remember the early days of my career when many designs were crafted using Photoshop. We would receive a .psd file and then, armed with a color picker and ruler, meticulously translate the design specs into HTML and CSS code by hand. The next day often brought design updates, and I would download the latest version, labeled as something like 'some-design-v13.psd.' I'd carefully identify what had changed and manually implement those changes. This cycle of revisions would typically repeat several times until we achieved the desired outcome. Afterward, a few additional rounds of revisions would follow, during which the designer would point out any discrepancies I might have missed. This collaborative effort persisted until we reached the desired 'pixel-perfect design.' Ah, those were the days!
Fast forward to today, design tools have evolved significantly. Designers have moved away from Photoshop to embracing various other tools such as Sketch. Subsequently, Sketch was often complemented by tools like Framer, InVision, Abstract, and Zeplin, each bringing unique features that were previously missing within Sketch itself. However, with the emergence of Figma, it swiftly gained traction and eventually captured the majority of the design tool market share.
In the world of Figma
Figma is more than just great; it has risen to become the top design tool with virtually no immediate competition at the moment. While there are still individuals or organizations that utilize other design tools, it's safe to assert that Figma has secured the majority of the market share.
Many things have led to Figma's impressive success. These include features like working together in real-time, strong basic design tools, the ability to edit vectors, tools for creating prototypes, great performance, a lot of useful plugins, a big and active community, and much more.
Amazing for designers, but less so for developers.
We've made big progress, and Figma has really improved how we work together and design. Many designers I've talked to can't think of much else they'd want from Figma – it seems to have almost everything covered.
As a frontend engineer, I don't gain as much from Figma as designers do. It's true that I can work more closely with designers, leaving comments right in the design and accessing the latest version without needing to download files. Also, Figma has certainly made it easier for me to gather design details using its inspect mode.
However, when I think about the last ten years since I started working – back when I had to use Photoshop – the way developers work hasn't changed much. I still need to closely examine each element and understand its specifics, manually write the HTML structure, and optimize SVG and image assets as needed. And let's not forget the numerous rounds of changes that we have to go through before achieving that ultimate "pixel-perfect" outcome, exactly as designers envisioned.
In many cases, we also need to come up with our own solutions and address any gaps. Sometimes, we have to consult with designers to cover missing scenarios or unique cases that weren't initially designed for – like hover and focus states, error or warning situations, mobile or tablet versions, and more.
When we decide to change how something looks, we have to do the whole process again - get the new designs, find the code we used before, and put in the changes by hand. To make sure we did everything right, we ask the designers to check the result. If needed, we make fixes based on their feedback.
Ultimately, when we see things from a developer's point of view, despite having a great design tool like Figma, we're still following a quite similar development process to what we did ten years ago.
Rise of low-code tools
In the last few years, quite a few low-code tools have emerged, providing a different way to build applications. This is a significant advancement for engineering and a major cost saver.
The basic idea behind a low-code tool is that you can create apps using a visual interface (where you drag and drop elements) and set up certain logical connections without needing to manually write any code. Once you're done, you can send it to the end user.
Tools like Retool, Bubble, Framer, Webflow, and others offer the ability to create a web app without requiring coding knowledge. And if you are a developer, you can do the same thing, often even faster, since your experience in engineering helps you understand many concepts more easily.
Need for flexibility
Don't misunderstand me, all of these tools can be fantastic for the tasks they were designed for. However, often they cater to a specific area and can limit your options for expanding beyond that.
For example, if you want to create an attractive landing page, use content management system (CMS) features, or run a marketing campaign, Framer or Webflow might be just right.
If you're focused on building tools for internal use, Retool is a good choice. And if you're aiming to construct your own social network (at least, that's what they say on their marketing site), Bubble could be the way to go.
Vendor lock-in
What's similar about all these apps? Apart from catering to a specific niche, most of them forge a bond that traps you with a vendor lock. In many cases, this bond can become much stronger than a marriage. Once you commit to using such a tool, breaking free becomes increasingly difficult unless you're prepared to abandon all the work you've done.
Getting locked in like this means you have to follow the tool's rules and, more importantly, accept whatever price they ask for.
Now, there is a way out, and that's called migration. But you can probably guess that moving your stuff from one tool to another is often really expensive, tough, and not something you want to do.
Escape hatches
While a few of these tools allow exporting code and others provide their APIs for custom functionality, the reality is that these options are often nothing more than last-ditch efforts, and in many cases, they're pretty disappointing.
The exported code usually ends up being cluttered with many unnecessary parts, making it quite challenging to read, understand, and especially maintain in the long term.
Furthermore, the APIs available for extensions are tailored to each specific vendor, meaning you have to learn something new for each tool you use.
What I, as a developer, want
If I intend to develop and maintain something over the long term, I'd also prefer to have complete ownership of the code, and to work with the technology stack I'm already familiar with. Unfortunately, low-code tools simply don't meet those requirements.
A tool from a parallel universe
So, we've got an incredible design tool for designers and low-code tools for building particular apps, but those options are still quite constraining for developers.
Now, let's take a moment to imagine - we're in a parallel universe where there exists an ideal UI development tool that enhances the way we design, collaborate, and create apps.
Let's begin by outlining the requirements:
Figma-like UI/UX (there's probably nothing better at the moment)
No/low-code development capabilities (enabling non-coders to contribute to changes)
No vendor lock-in (the freedom to leave the tool without extensive migration)
Clean, readable code that matches your existing codebase (generated code integrates seamlessly)
Easy extension with your chosen tech stack (avoiding the need for vendor-specific APIs)
Git integrations (directly commit changes from the app, no need to learn Git)
Preview code changes within the app (test end-to-end results without deploying or building)
Alternative workflow
Now that we're considering a tool that hasn't been realized yet, let's explore what the ideal workflow might look like.
Just as we do with today's tools, we'd likely begin by designing each screen of the application, outlining different states and scenarios that users might encounter. The designer could handle all of this using the same familiar design processes, as it's very similar to Figma. However, unlike our current approach, we wouldn't have to manually translate these designs into code or move generated code into our codebase by hand.
Moreover, we could not only preview and test all the interactions within our UI directly in the application, but we could also directly commit the changes to our codebase, eliminating the necessity for a manual code handoff.
Now, at this stage, we'd have a basic UI structure without the business logic. The subsequent step involves connecting our UI with the backend services. Since this tool generates code in your existing code style and aligns with your chosen tech stack, you can seamlessly begin coding on top of it.
As an engineer, I'd focus on getting data from and sending it to the API. I'd use UI parts to show the fetched data and include the necessary logic for the app to work well. All of this could be accomplished using my preferred framework. Essentially, I would no longer need to handle the visual aspects of the application.
Now, imagine we get initial feedback from users and decide to tweak our UI. Instead of going through the process of creating a design, making a Jira ticket, and planning engineering tasks, the designer can directly access the tool. They can make the required changes and seamlessly incorporate them into the codebase without extra engineering effort. This can be done while keeping intact all the work that engineers have previously added on top of the generated code.
Let's take it a step further: imagine your marketing team wants to try out new copy text or a different product image. You can provide tool access to other team members, letting them make these changes themselves. After all, it's as straightforward as using any other visual tool.
What if you want to stop using this tool for any reason? Let's say an even better tool comes along. You can simply stop using the tool because you own all the code and aren't tied down by the tool. It's like hiring a different developer for the job. There's no need to stress about moving the entire codebase to something else.
A tool from Kubi Design
Although I can't predict the future of UI design and development, I have a clear vision of how I'd prefer it to be.
The team at Kubi and me have been working hard to create a tool that meets the requirements I mentioned earlier. It's a long and challenging journey ahead, but so far, no technical challenges seem impossible. It just requires time and thoughtful solutions for each requirement.
We've already established a solid base for designing UIs, offering a user experience quite similar to what Figma provides.
We enable immediate previews of the final result's appearance, all within the app itself.
We generate clean code that creates a pixel-perfect result.
Has zero vendor dependencies
Our focus is on React.js and Next.js ecosystem for now
And we offer Github integration for automatic synchronization of code and assets.
Once you have UI code within your codebase, you can choose your preferred framework and proceed to incorporate any required business logic, all without needing to learn vendor-specific APIs.
Certainly, we still have a lot of features to add, and there are instances where things break or don't function exactly as anticipated. Nonetheless, this should provide you with a solid understanding of how the team and I envision the future of design and UI development. We're striving to construct an alternative approach to work.
If you've reached this point, you might be curious to give the app a try. Signing up is completely free, and we'd greatly value your feedback.
Final thoughts
Even if our perspective on the future of design and UI development turns out to be incorrect, what changes would you envision for the future? What aspects would you like to see improved? Should we continue with manual hand-coding indefinitely?
 | A guest post by
|