Where we come from and the current situation

I started designing for the web in 2011 and working in 2013. One of my first jobs was at Microsoft as an intern in their design team located in Helsinki. At that time most of the resources for UI were made in Photoshop. Yes, Photoshop, a tool for editing photos was the same for designing web pages. Using this tool, I could export images that were passed to development and they would do all the magic to bringing it to life through code. But, they didn’t coded it as I expected them to do. The design never fit exactly what I had designed and it frustrated me, a lot. I didn’t understand it, so I decided to learn how to code frontend, to understand what the problem was and how it could get it solved.

Some time later, I started learning how to code HTML and CSS properly and very soon I was already writing production code in a smaller company. Of course, not leaving the design work. That’s when I began to realize that there was something weird, even a bit wrong, with the process. Why did we design static images when the web was not? Why couldn’t I design a button that fit its content instead of adjusting its margins manually as it did when coding on the web? Why didn’t my designs adapt to the screen’s width with relative styles as I could make it do when coding? Why did it seem like I was designing in “position: absolute;”?

And not only that, while the designers were doing handicrafts, in development they used Git as version control, working as a team and in a totally safe and organized way thanks to it.

Until one day, Sketch came out. I remember that I started using it at the end of 2014. It seemed the revolution, surely the designers who are reading me right now can affirm that our quality of life was improved so much. Finally a program only to design UI!
A program where there were not a thousand buttons that you didn’t need, where you couldn’t not only export images, but also SVGs! And everything was much faster and easier than using Adobe. It also had plugins that looked like super powers to me compared with the old-fashioned Photoshop.
But the really game-changing feature was its symbols. We could finally save designs, reuse them and sync them throughout the tool, it was great.

Also new other tools like Zeplin came out. This ones helped the developers (that didn’t have Sketch) to implement our designs. But let’s not fool ourselves, the CSS generated by Sketch or Zeplin rarely ends in production or is event relevant. Some stuff like colors, spacing or shadows can be useful but nothing else. We don’t even use plain CSS in most of the frontend projects, but we use CSS preprocessors like SCSS.

Some time later, in 2017, Figma appeared in the market, and it has gained a lot of attention for these reasons:

• It runs on the web and have a free initiation plan.
• Real-time collaboration in the same file.
• Version history (not version control tho)
• Web API which we can use to dynamically export information from any Figma file.
• Plugins, surely the strongest feature of Figma at this time. Although Sketch already has plugins, thanks to the web API that I mentioned before, Figma’s plugins are much powerful.

I think that both real-time collaboration and version history is a great step, although I’d like an independent version control to the program and preferably hosted where the code is, to centralize resources. What it surely has to improve is its API, where the results it returns are still very poor, especially related to components and styles, which makes it impossible to connect frontend and design, one of my wishes for this API.

We haven’t still solved the key problems

Yes, Sketch or Figma are much better than Photoshop and the industry continues to evolve constantly, but we haven’t still solved the key problems:

• We design and implement the same website 2 times and there are even differences between them! How much time have we lost designing a rule for x pixels spaces and then in development has not been implemented like this or we haven’t even been able to apply that rule in all the elements on our design? It’s not the developer’s fault, nor is it the designer’s, but the medium (the design tool) which is the only one to blame. The difference between the designed concept and the developed product will always exist as long as they are separated.

• Current tools don’t allow us to design responsively. I wish we could make relative positions in design. I would love to have CSS media queries to structure the content based on its width. I hate designing the same screen 3 times because it can’t be designed to fit its width. Waste of time. Inefficiency. As a UX Engineer (design and front), I end up not designing the responsive versions for other devices on Sketch because I design them modularly in one width and then I adapt them responsively in the implementation.

• The web is not flat, it’s not a blank artboard. We are used to creating static drawings that don’t represent reality as a whole: the web is not images or vectors, it’s not flat, it has interactivity. The web also has states (hover, active, focus, visited …), but how are they represented in the flat world of design nowadays? Repeating designs. We design that same element 4 different times to represent these states unreally and we don’t see how the real result looks until it has been implemented.

• Working without version control means that we cannot work as a team in the same file in a completely organized way. Yes, Figma has real-time collaboration and version history but we are still years away from being able to document and create different versions of the project and then compare and join them as we do with the coding version controls. And no, tools like Abstract for Sketch don’t seem sufficient, since they are not based on web code and we cannot compare objective differences from the same medium.

• Visual bugs end up in production because we don’t have acceptance tests for our designs. When I speak of testing, I speak about technical acceptance testing, not user testing. Imagine having a way to verify that all the colors used in the design are the official colors. Or another example, that all the measures used are multiples of 8 as defined in the design system. It would be very useful, right? On the development side they are very used to do testing that allow them to minimize possible errors in their work, designers don’t have that when designing, and this leads to visual bugs in production.

Why is this happening?

Many UI designers still keep the graphic design’s mindset, as if designing for the web was the same as designing for offline but with different measures or rules. No, it’s not like that. The medium of the product is totally different and our tools should change depending on it.

That is why I believe that the tools we use to design websites should also not be the same we use to design native mobile apps. They don’t work in the same way, they aren’t developed using the same technologies, they don’t have the same interactions and they shouldn’t be designed in the same way. SwiftUI has taken the step of being able to design with the same code used in development, making it the most suitable tool for designing iOS apps.

The main problem is to separate the concept and the implementation. Do we really need to separate it? Why? As a result we get twice of work with idealized sketches that don’t fit reality and generate frustration between the design and development teams.
Unlike other design modalities, web UI designers have the privilege and great luck of being able to use the same medium where it is implemented to conceptualize that design. But the current design tools are far from how the web works, they keep the mindset of separating the concept from the implementation as is done in all other design modalities. You cannot design buildings in your same medium, using those same buildings. But we can design using the web, since its material (HTML, CSS and JS) is flexible enough, through a graphic tool, to allow us to conceptualize having the same speed and fluidity as with a vector-based tool like Sketch.

As Colm Tuite mention in his article: “Design tools shouldn’t need to resemble or reflect the web and its nuances — they should just BE the web.”

Design systems

Our favorite topic, design systems. But we barely mention how incredibly difficult it’s to maintain two design systems. First, the one maintained by the design team and second, the one maintained by the frontend team. And when you have two different projects with different technologies and maintained by different people, they will never, ever, have a total consistency. And therein lies the problem, the duality.

I get tired of seeing very nice design systems that when inspect their code I realize that those websites are implemented differently than how they were designed. Which is silly, because why to spend time defining a design system if your frontend team ignores it or can’t implement it? A concept that doesn’t get developed well or at all is just useless.
Wouldn’t it be better to have a single design system? A single source of truth?

What kind of tool do we need to solve these issues?

I imagine the perfect design tool kind of like a Storybook where the designers could have the components of a design system written in code, the same ones that front-end would use in production, so we wouldn’t need to maintain two design systems, we would only have a single one.

By dragging we could combine these components to create organisms where CSS would be applied from a graphical interface that could reflect the real properties of the web, such as relative measures, media queries, flexbox, CSS Grid…
The same could happen with the animations, we could animate those web elements with CSS animations. And most importantly, our designs would stop being JPGs to be HTMLs. Accessible, responsive and above all, real.

In addition we would solve the version control problem and the creation of acceptance tests. Being a tool based on web code there would be no problems with creating that version control. You could preview by graphically comparing the HTML files displayed by the browser and choosing which version you stay in addition to objectively viewing the web code that has changed. Also, there wouldn’t be any problem creating any acceptance test since code would allow it.

Luckily, there are already some tools that work like this and although they may not solve all the issues listed in this article, they are on the right track.

• Framer X: its hype in 2018 was tremendous with the announcement that their designs could be exported to React or we could design using components previously programmed in React. Although it was a huge step, we later discovered that the code isn’t intended to be production ready but to resemble React as closely as possible. And here we find the main problems:

1. Separating design and development by not creating production ready code means working twice.
2. Locking yourself in a framework. I believe we should try to use web standards such as HTML and CSS for styling as much as possible. Using React, Vue or Angular should be a JS layer above styling that controls the reactivity of the webapp and it should be delegated to the frontend team, not to the design tool.

• Webflow: It’s a great and mature option and it meets the vast majority of points. The only problem is that the generated code is saved in its own hosting and it seems impossible to edit out of the graphic editor.

• Modulz: falls into the same problem as Framer X when exporting code only in React. The main advantage is that it exports production ready code and it uses CSS properties for design styles such as flexbox and native states.

• Hadron: although it’s still in version 0.14, it’s going in a very good direction. On its website we can see how they solve all the problems raised in this article (including responsive design) with mediaqueries or grids made with CSS Grid. I think it’s very promising.

• Mason: It is a tool to create UI code from a graphical interface by replacing the text editor. It seems to have a lot of potential.

Finally, I will not go into the “debate” of whether UI designers should know how to “program” (what a broader term!) Because I think there shouldn’t even be such a debate.
Being a UI designer and knowing how the web works and therefore HTML and CSS, which are purely declarative languages, is as basic as knowing physics as an architect.
Design tools have to help us working through graphical interfaces that provide us speed versus code editors but the implementation should be the same.

Continue reading on the subject

• Design tools are holding us back by Tom Johnson
• Design tools are running out of track by Colm Tuite

What do you think about it?

And you, what do you think of the current design tools?
You have already read my opinion about it, I would love to read yours on Twitter @marinaaisa