Lost in Translation

Here’s a scenario that should be familiar to any designer in the software industry: you’ve just finished working on a great design. Everybody’s happy with it: the other designers, the developers, the boss. Now it’s time to implement it, and make it into a real product. The developers show you their first version. And it bears as much resemblance to your original design as a Halloween cat costume resembles a real cat.

You try to fix this. You give the developers detailed instructions. Move this image two pixels to the left. Make that transition 0.2% faster. Change the border width on the button component. For every such change, you have to wait. The developers are great, but sometimes they don’t get your exact meaning, and other times the team has other priorities, and for weeks, or even months, you’re stuck in the same loop, just trying to make the product look the way you want it to.

Hi, I’m Anat, Head of UX at Codux. In the past few years I’ve been working at Wix as a Product designer, I’ve felt how we’ve been running through those challenges again and again. That’s why I was thrilled to help lead the effort of creating a solution, one that can give us designers control of our designs. This is why we built Codux.

Introducing Codux

Codux is a visual editor for React projects. It presents the project’s code in a visual editing environment, which allows designers to work on the actual source code without coding. This means no more endless ping-pong between you and the developers since your changes affect the code directly. It means no more guessing how the final product will look, as what you see is what you get. It means better communication between everyone involved — instead of long explanations and design documents you just focus on design. And it means that you don’t have to delve into the intricacies of Javascript and React — you just drag and drop, and make changes in property panels.

This sounds very nice in theory, but how is it in practice? Here’s my own experience, working as a designer, before and after Codux.

The Magic of Quick Fixes

The first time I used Codux was while working on a thumbnail component. I designed it in Figma, delivered it to the team, and wasn’t surprised to see that the resulting component was not how I intended. My initial course of action was exactly what you’d expect: I inspected the component both visually and using the browser’s Developer Tools, and compared what I found to my Figma design. This way I found that the padding, the colors and the shadows were incorrect, and the footer had the wrong border.

But this time, instead of talking with the developers and submitting a list of fixes, I was given the chance to use Codux. It was so exciting!

I did not need the browser’s Developer Tools anymore, or anyone’s cooperation. Opening the project in Codux, I could see for myself how and where the design was implemented in the code. I’m no coding expert, but it didn’t matter much, because the information was also presented with familiar visual displays and controllers. I could change the values of any parameter, any color, any border of the component, and my choices would become a part of the code. I could play with this component until it was perfect.

Which I did.

And the best part? It took only a few minutes.

With Great Power

Excited about my quick progress, I couldn’t wait for my fixes to become a part of the project on production. However, it became clear to me I still needed to learn a thing or two before utilizing the full power of Codux.

Dealing with code, even if you’re not a coder, means cooperating more closely with your developer teammates.

I had to get familiar with Git, which is used by all developers these days. Without getting into details, it allowed me to work safely on my own version of the product, have control on when and with whom I want to share my changes, and get reviewed by the developers in my team.

It took me a few minutes to get the hang of it, but eventually, proudly, I submitted my code — me, a designer! — to the project. What joy!

Well, again, turned out my joy was a bit premature. Dealing with code, even if you’re not a coder, means cooperating more closely with your developer teammates. Every project has its own internal coding conventions, and the same goes for teams and companies. But the good news is that all this makes communicating with the team much more streamlined and effective. For instance, you don’t call the component “Oh, this thumbnail over there” anymore. You call it BoardCardView, because that’s how it’s coded, and every person on the team knows exactly what you mean by that. So, no more confusing descriptions and having coders spend days on the wrong components.

All this may sound complicated, but in fact the learning curve isn’t very steep. Less than a day after fixing the parameters of my card component, the proper version was merged into the project’s code and went on to production. How’s that as an alternative to the endless please-fix-my-color/shadow/border cycle? How’s that for a non-coding designer?

The Deep End of the Pool

After my initial success, it still took a while longer for me to realize just how much this will impact the way I work. The deeper I got into the project, the more changes I made using Codux, it became evident that this was a paradigm shift.

As a designer, I prefer investing as much time as possible on design, and as little time on tedious bureaucratic tasks. Before Codux, I expended a lot of effort in explaining my design to the team, maintaining my Figma files, and trying to bridge the gap between Figma and the reality of the web. But Codux changed all that. Now, I can implement the changes in just one place, directly into the source code, and then immediately visualize their impact on the entire project.

By accessing the real project, I can understand my designs better, test faster, and experiment with new ideas and designs within the real constraints of the web. My processes became iterative, minimizing back-and-forth communication. And so my fellow designers and I can take on additional tasks, while the developers can concentrate on business logic.

The Future of Web Design

My experience working with Codux convinced me that it’s more than merely a helper for designers: it’s a tool for the entire development team. Not only is it simplifying and improving our collaboration, but it brings us together as a team. Suddenly it’s not just “you do the code, I’ll do the design”, but a work environment in which everyone’s equally involved with the product.

Codux was developed out of necessity, answering a real pain point for people of different professions using different terms and tools to define the same things.

Suddenly it’s not just “you do the code, I’ll do the design”, but a work environment in which everyone’s equally involved with the product.

Here on the Codux team, we proudly follow the long-time Wix tradition of making technical interfaces visually editable. Now that designers can build a product’s UI visually and directly into production-ready code, we’re ready to share this with the world. It’s currently in beta and free to use — we’ve already started to spread the word and there’s a rapidly growing community of people and organizations using Codux. I invite you to join it! You’re welcome not only as a user but as a collaborator too. We’d love to have your input, gathering feedback help us shape the best possible product. Together, we can build a more productive, inclusive, and effective future for web design and development.

Try out Codux

Is there a topic you want to see covered by the Wix UX team? Let us know by filling out this form.