Building with Lego blocks, was one of my most loved games as a kid. I love looking at my kids' builds and playing with their creations. At some point, I discovered that there is an engine that can power some creations. Many years later I was introduced to Lego Mindstorms. This was when I was building projects while doing my computer science degree in MiLab.
Today there are so many Lego categories. However, the basic Lego blueprint has remained the same. Lego does create new types of Lego parts in new shapes or that can introduce new mechanics - BUT the basic elements are the ones that keep the simple and fun experience. I can add new Lego parts to some new ones, and buy the new Lego Mindstorms - and it will easily help me build the best experience since they did some homework and provided the right elements for us Lego lovers to use.
The Analysis, and the Connector
Just like Lego blocks, we're building a tool that empowers designers to create and deliver code as almost as if they were part of the development team. To gain a comprehensive understanding of how designers truly work, we conducted extensive research on over 150 design systems. These included public design systems and component libraries from various organizations. We looked at Storybook servers, Figma and Framer files, as well as GitHub repositories, to identify common needs and challenges designers face in managing their design systems. Finding the Common Denominator.
Our tool is designed for both designers and developers, so our goal was to identify the largest common denominator that would solve as many problems as possible for both parties. We focused on organizations looking to build or upgrade their component libraries, enhance their UI, or adopt a design system for the first time.
To bring all of this together, we realized we needed two key ingredients:
- A design tool for designers to build and create simple and complex components
- A way to transition between the abstractions the editor produces and the actual code
We aimed to create a process that closely aligns with the workflows of both designers and developers, facilitating easy integration and fast delivery.
Crafting UI Elements - with Jux
Elements are the building blocks designers can use on our code-based canvas. They can craft these elements and then push them with ready-to-be-use generated UI code to the developer. But a Jux element is more than just lines of code or visual properties as you might find in other design tools.
We looked at common UI patterns and best practices, such as a button with optional icon slots on the left and right, plus text in the middle. By providing these configurable elements, designers can include or exclude certain features as needed.
This approach allows us to incorporate interactions (aka mini prototype features) into the code. We provide a live canvas that renders the element as it is designed, combining the template, design, and code. The template is the abstract blueprint, the design is the “CSS,” and the code includes some “markup” and the prototyping features we provide. This working method creates flexibility, repeatability, accessibility, and reduces adoption friction.
As we progressed, we realized that in addition to atomic elements (see my past blog post), we needed to introduce "templates". A template provides a basic structure, like a header, body, and footer in a modal, which can be filled with various other components, assets or elements like divs, buttons, forms, etc. This allows designers to create reusable patterns while still customizing the content.
Balancing Simplicity and Power
Designing with Jux’s elements is a balancing act. We want to give designers the building blocks they need to be productive, but also allow them to implement more advanced interactions and behaviors when required. All this is done on a code-based canvas, not a vector-based one, to maintain the creative freedom designers deserve. When building a design system, a feature, or a product - consistency in design, use, user experience, and code is crucial. Reusability is key to avoiding reinvention. One of the attractive features of Jux’s elements is that designers get a mini prototype with the user interface that they can fully customize while maintaining reusability from both the developer's and designer's perspectives.
This creates a collaborative process where the designer and developer can communicate using the same tools and the same language. Designers build their features and, along the way, create a design system that is managed by developers and is reusable. By designing elements this way, Jux enables a workflow where consistency and reusability emerge naturally. Designers have the flexibility to customize elements as needed for specific features, while the elements themselves provide guardrails and best practices. This balance ultimately leads to a more cohesive, maintainable system created through collaboration.
Onboarding, with Elements
A designer's intent when creating a new design or flow roughly falls into two categories: Building a design system or creating a flow of screens for a new feature. In either case, the first thing they do is play with their first component by dragging an element onto the canvas.
We provide some scaffolding for these processes—designers can change everything about our elements, while the basic internal logic is maintained to ensure the developer’s workflow remains intact. This teaches them that while some logic is fixed, every aspect of the design is flexible, and some elements come with “prototyping-like” capabilities.
We believe that there is another “wow moment” when designers switch to “live mode” and interact with the element as if it comes to life. This experience is familiar to web builders but not to product designers. They see that everything changes and responds. It's not just something they created - they have a new superpower. They can write in an input and see the text appear, or click a button and watch it go through hover and active states.
This is when they realize they're in a new world, with new mechanics. They can add elements to a library and start to manage something bigger. It's an experience reminiscent of other design tools, but taken to a new level as it all translates directly to code, that developers love.
The Road Ahead
We have a well-organized plan and roadmap for the elements we want to introduce, and we are adding more elements to the system monthly. As stated before, these elements are crafted in a way that helps create new experiences for designers, and allows the user to create simple yet sophisticated products. Some of these elements include Select, Radio, Checkbox, and others. However, the complex elements that we're aiming for include search-box, tables, and charts that are used by many products, and that are hard to design, build or manage.
In The Way of Kings, Brandon Sanderson wrote, “Journey before destination”.
I can relate to this while writing about the very early steps of product building. I love the journey, and I will continue to share more as Jux continues to evolve - brick by brick.
