Managing tokens across light and dark modes, keeping component logic consistent, and syncing it all into production-ready code shouldn’t be a full-time job.

And yet, that’s exactly what we kept hearing from people - so we built something new.

Introducing Design Token Collections + AI-powered Tokenization‍

a way to extract, organize, and maintain your design tokens directly from existing work.

It’s here. And it’s system-aware, AI-native, and built for your real-world workflows.

Why we did it

From day one, Jux has been about rethinking the relationship between design and code - not just exporting one into the other, but blending them.

But here’s the thing: many of you didn’t just want to prototype or tweak. You wanted to migrate your actual design system into Jux - tokens, architecture, logic and all - without starting from scratch.

The blocker?

Manual token creation. Naming conventions. Theme variants. Light/Dark themes support.

Even with our AI and canvas already in place, token setup was friction. So we asked:

“What if Jux could do that for you?”‍

How we did it

The result is a new AI constraint mode in JuxAI, designed specifically for systematic token extraction.

Here’s how it works:

• Tag components in your existing design

• JuxAI detects token candidates: colors, spacing, typography, radii, etc.

• It builds organized token collections - complete with mode variants (e.g. light/dark)

• You review and approve, or tweak as needed

• Your token system is now live, reusable, and consistent across your canvas

  We also allow you to preserve existing token libraries. If you already have a system, you can prioritize existing tokens over new ones - ensuring your architecture stays intact.

  Tokens then carry forward into code, powering live prototypes and reusable components via Jux MCP.

  No duplication. No loss of context. No dev handoff nightmares.

  ‍

  Why it matters (for Jux and for you)

  This unlocks the full potential of what we call AI-native design engineering.

  It means:

  • You can bring your existing design system into Jux without compromise.

  • You can build net-new systems directly in the editor, and trust they’ll scale.

  • Tokens are no longer a blocker - they’re an asset that powers design and code in sync.

  • Prototypes aren’t throwaway - they’re production candidates, enriched by your system.

  For us, it’s a step toward a bigger vision for Jux:

  A single environment where design and development speak the same language, and where systems grow organically through use - not documentation.

  For you, it’s a chance to stop treating tokens like overhead, and start treating them like infrastructure.
  

  We’re just getting started, and you can:

Get started for free

xoxo » the Jux Squad

The debate about whether designers should code is old news — and frankly, outdated. The emergence of the Design Engineer role is a testament to that. This hybrid role has existed for years, quietly shaping teams in companies like Notion, Vercel, and others, often under different titles. Traditionally, these were just “designers,” but they stood out because of their ability to code and contribute production-ready solutions.

These individuals broke away from the standard “designers know code but don’t code” mentality. They actively delivered production-ready code in specific areas, prototyped complex interactions in code, or laid a solid foundation for engineers to build upon.

In 2024, the Design Engineer role became widely recognized, with companies officially embracing the title. Tom Scott, a leading design recruiter, recently listed Design Engineers among the most in-demand roles. Job boards like Design Engineer.io have popped up, dedicated exclusively to this emerging position.

Interestingly, many of these roles seem tailored to experienced professionals. Yet, the skill set is still new, and the talent pool isn’t as saturated as traditional design or engineering roles. This creates a unique opportunity for juniors who have the right foundation, mindset, or adaptability to carve a path into this space.

What is a Design Engineer?

Before exploring how juniors can break into this field, let’s define the role. Design Engineers are hybrids: professionals who work at the intersection of design and development, bridging the gap between the two.

David Luhr’s article succinctly describes the role as “design work with code.” While simple, this definition underscores its essence. A Design Engineer:

• Contributes to the codebase: Unlike traditional designers, Design Engineers write production-ready code.

• Makes design decisions: Unlike traditional engineers, they also handle non-technical design aspects.

They work end-to-end, which involves:

• Designing user interfaces and focusing on visual aspects.

• Crafting interaction-heavy experiences.

• Prototyping in code.

• Shipping polished, production-ready front-end implementations.

To succeed in this role, you need:

1. Exceptional Visual and UI Skills

To excel as a Design Engineer, your UI work must go beyond the basics taught in courses or bootcamps. The expectation is to deliver polished, production-ready designs that align with the standards of companies like Linear, Vercel, or Clerk. While you don’t need to match their style, you should aim for similar attention to detail and balance.

• Clean and Balanced Layouts: Master fundamental design principles like alignment, spacing, and hierarchy. Use tools like Figma’s Auto Layout to create scalable, consistent designs, and ensure you understand responsive design principles.

• Typography and Visual Hierarchy: Strong typography is essential. Learn how to create a clear hierarchy, balance font sizes, and ensure readability across devices. Study typographic scales and experiment with tools like Type Scale to refine your skills.

• Interaction-Ready Design: Focus on more than static screens — anticipate hover states, active states, and micro-interactions. Understanding these dynamic elements ensures a smoother transition when your designs move into code.

2. Front-End Coding Expertise

To turn your designs into production-ready interfaces, you’ll need a solid understanding of front-end development:

• Core Languages: HTML, CSS, and JavaScript are must-haves.

• Modern Frameworks: Familiarize yourself with React, Next.js, and styling solutions like Tailwind CSS or libraries such as shadcn.

• Responsive Design: Learn to create layouts that adapt seamlessly across screen sizes using CSS Grid or Flexbox.

3. Motion and Interaction Design Knowledge

Motion often defines how users experience an interface, making interaction design a valuable skill for Design Engineers:

• Timing and Feedback: Master principles like easing and duration to create smooth transitions that enhance usability.

• Practical Tools: Experiment with Figma’s Smart Animate or dive deeper with CSS animations and libraries like Framer Motion.

A solid foundation in motion can elevate your designs, but it’s not always required — it’s a great differentiator when applied effectively.

While specific requirements vary by company or product, these skills form the foundation of a Design Engineer’s toolkit.

Why This Role is a Steep but Rewarding Path

At first glance, the Design Engineer role might appear daunting, especially for juniors. The reality is that this path requires deep expertise in at least one domain — design or development — before building proficiency in the other. However, for those willing to put in the work, it can be a fulfilling and unique career.

1. Build on Existing Strengths

This role is particularly suited to individuals with strong foundations in one field:

• Developers with an interest in design: If you already have front-end coding expertise (e.g., React, TypeScript, or Next.js), start learning about design principles, interaction design, and UI craftsmanship.

• Designers with a knack for technical problem-solving: Designers who excel in visual/UI design can explore coding fundamentals like HTML, CSS, and JavaScript, then gradually dive into frameworks like Tailwind CSS or component libraries such as shadcn.

2. Leverage AI for Acceleration

The learning curve to become a Design Engineer is steep, but leveraging AI tools can significantly accelerate your journey. These tools are not just productivity enhancers but essential companions for learning and experimentation:

• For coding: AI tools like GitHub Copilot or Cursor can help you write better code, debug more efficiently, and learn advanced concepts by generating explanations and examples.

• For design: Generative AI tools can assist in exploring visual concepts or automating repetitive tasks, giving you more time to refine and polish your work.

• Future-proofing your skills: As AI continues to reshape the developer and designer landscape, becoming proficient in using these tools ensures you stay ahead of the curve.

A word of caution here though. I do honestly believe that this can be an excellent fit for people early in their career and we will see the experience levels start to vary in this field very soon. However this role demands high standards. If you just learned the fundamentals of design and have not worked with code at all before, this is likely not the optimal for you right now. Instead focus on mastering one half of it before approaching the next. There is nothing wrong in learning the fundamentals of the other already but focus will get you further than riding two tracks at the same time if both is new to you.

How Juniors Can Break Into the Design Engineer Role

1. Build Your Skills

Regardless of your starting point, developing the right skills is critical. Focus on:

• Polishing weak areas: If coding is your weak spot, start by learning HTML, CSS, and JavaScript, then move into React or Next.js. If design is your weakness, master tools like Figma and build your visual design skills. Ideally you bring the basic knowledge here already. Also make sure to utilize AI as a help here. Many designers have accelerated their coding learning curve by making use of ChatGPT, Claude or Cursor to teach and enable them to ship code.

• Crafting polished projects: Create small, interaction-heavy components to showcase your ability to merge design and code seamlessly. You can for example use Framer to experiment and play at the intersection by using code components inside the visual builder or play around in VS Code and build your own little playground. Post these on platforms like LinkedIn, Post.cv, or BlueSky to attract attention of other designers.

2. Curate a Hybrid Portfolio

Your portfolio should showcase your ability to bridge the gap between design and code. Include:

• Small interaction patterns or micro-projects that demonstrate specific skills.

• Two to three larger case studies of shipped or fictional projects. If working alone, document how you would collaborate in a real-world setting.

• An impressive portfolio website that exemplifies your ability to create functional, visually engaging digital experiences.

3. Master the Right Tools

Tools are something we are going to see a lot of movement in over the next few years in this area as design and code gradually continue to blur. For now a Design Engineer’s tool stack might look like this:

• Design Tools: Figma for UI/UX design, emphasizing interaction-ready designs with clear annotations.

• Development Tools: VS Code, GitHub, and frameworks like Tailwind and Next.js.

• AI Assistance: Use coding assistants like Cursor or GitHub Copilot to accelerate your workflow and learn on the job.

There are emerging tools like Jux that are already operating at the intersection of design and code but they do require a firm grasp of both design and development. Similar to how Figma’s Code Connect integrates designs into codebases, Jux helps teams (or individuals) streamline their processes of translating design to code with one source of truth.

4. Network and Learn from Others

Engage with professionals in the field:

• Reach out to Design Engineers on LinkedIn or ADPList for informational interviews.

• Join communities or create your own to connect with like-minded individuals and drive conversations about the role.

The Role’s Availability and Salary Potential

While this role isn’t about chasing a paycheck, it’s worth noting that Design Engineers tend to earn more than their design or engineering counterparts.

US salaries range from $120k to over $250k, with some senior roles crossing $300k.

Other markets (Europe, Asia) are still developing but represent opportunities for early adopters to gain an edge. I’d anticipate a rise in these roles for these markets in 2025.

Conclusion: The Path Ahead

The Design Engineer role is demanding, requiring a unique blend of skills across two disciplines. However, for juniors with the right background and determination, it offers a chance to stand out in the competitive design and development job markets.

If you’re a junior with a knack for either visual design or coding, this could be your opportunity to break into an exciting, evolving role that combines the best of both worlds. Dive in, start learning, and explore how you can shape the future of design engineering.

This is the 2nd part of a two-part series.
In part 1 we explored various scenarios for explicit rules involving width and height, different units of measurement, gaps, distributions, and many others, examining what's available in various tools.

In part 2 I’ll cover more examples of how different design tools tackle different situations of expressing implicit intent with explicit rules. 

Let’s dive in. 

Layout, order and position

As we discussed in part 1, adopting a rule-based approach might not be the default for designers, but it proves to be the most scalable. 

Let's contextualize this within layout decisions, particularly when some objects are contained within another object. In this scenario, two sets of rules are relevant: 

1. Rules that dictate how the parent object should order and position it’s children

2. Rules that specify how each child element should relate or override the parent-imposed rules

I’ll be providing a number of examples below that put these rules into practice.

Example 1: Wrapping cards inside containers

Let’s say that you want to lay out five different cards from left to right, from top to bottom, where only three cards fit the container in its current width:

There are a couple of ways to go about it, depending on the design tool. In Figma, the best way would be by assigning auto-layout to the parent frame and setting it to wrap, aligned top left. In Jux as in CSS, you would use Flexbox on the parent frame, activating wrap, selecting start in the align, and start in the justify options.

Lastly, as a refresher from part 1, the implicit intent in this case would be: “Regardless of the width of the parent container, keep laying more items until there’s no more space to place another one, then move to the next row and continue from left to right”.

Example 2: Changing card position while maintaining layout

Now, consider the following intent: “Upon hover, each card ‘jumps up’ 20px without disturbing any other card.” In vector tools, there’s no way to express the concept  of changing something’s position without affecting the layout. This is only possible if there’s a positioning mechanism like in CSS that allows for position: relative on the hover state of the card, while still reserving the space occupied by the card. Code-based tools like Jux, Webflow can support this, but strangely, Framer does not.

Interestingly, Figma supports another positioning option, which is absolute, even within auto-layouted frames. This feature is particularly useful when you want to position an object (like a notification) on the top-right corner of an expandable button and the object will always be pinned in the same place. Moreover, in standard, non auto-layouted frames, all constraints are variations of position: absolute even without explicit selection. 

In code-based tools like Framer, Webflow, and Jux, you can simply select the type of positioning to be absolute, regardless of the layout decision. However, in Webflow and Jux this is not the default setting.

Below, you can see how the initial desired intent aligns with the explicit rule in Framer:

Example 3: Child item independence

What if you want most of the items inside a container to stretch, while one item aligns center? For example, when laying out a narrow container with a title and several paragraphs, you may want the title to be center-aligned, but the paragraphs, due to their multiple rows of text, should align left while filling the width of the container. 

The implicit rule could be summarized as follows: “Make all these items stretch but this item align to the center, regardless of  the parent’s width and the number of items I add”.

Below, you can see the explicit rule mechanics in Webflow:

For this use case, Webflow is the easiest tool. This is because you can use the ‘Flex child’ module to override the general alignment that was set by the parent container— so you don’t need empty containers, just the title and paragraphs in one parent container.

Meanwhile, in Figma, it's more complicated because you can't override the auto layout's alignment setting for a specific child element. Therefore, you'd need to create another frame to contain the title and set it to center alignment.

Example 4: Stacking order

Let’s imagine you’re designing an avatar group widget, where the avatars overlap each other. Your design intent is as follows: “When hovering over any avatar, it should appear above all others, regardless of its position in the idle state”.

To achieve this effect, we need to use a concept called z-index. However, in Figma, doing this would mean giving up the auto layout of the avatars' container. Figma's auto layout allows you to specify whether elements are arranged first on top or last on top, but this feature is primarily geared towards establishing the initial stacking order. It doesn't provide the flexibility to dynamically adjust the z-index of individual elements. The good news is that in CSS and code-like tools, you can specify that in hover state, the z-index will change. This means that in the idle state, the avatars maintain their default z-index order based on the flexbox layout, but upon hovering, the z-index of the hovered avatar is increased, causing it to be above all other avatars.

Example 5: Padding and margin

The position of children elements inside a juxparent container is also influenced by two important properties of the box model: padding and margin.

Padding: A top-left padding of 10px will push any child element 10 pixels from the left and the top sides of the parent container, even if the alignment is to the left. You can think of padding as a short explicit variation to the implicit intent of: “Make sure nothing comes closer than 10px from the left and top sides, regardless of its size or any other rule it has.”

In Figma, padding only exists for frames with auto-layout turned on; ordinary frames don’t have this ability. In CSS, however, padding can be applied in all cases and situations, regardless of the display type. It is worth noting though, that when the child element has ‘position: absolute’ it completely ignores padding. Similarly, when it has ‘position: relative’, its visual placement ignores padding (although its original placement does respect the padding).

Margins: Margins are also useful for defining ‘safe’ space on each side of an object or creating space between objects, especially when the spacing is irregular (and using the gap feature in auto-layout / flexbox is not enough). Now, it’s important to note that neither Figma nor any other vector tool out there supports margins. So, the only way to ‘fake a margin’ is to wrap an element with a frame and set the frame’s padding equal to desired margin distance. But this is problematic because it leads to unnecessary bloat of frames that are only present due to the inability to use margins. In Jux (and of course CSS), margins are freely available for use in all directions and cases. 

So basically, when you create a 30px margin from the bottom of a component, your implicit intent would be: “No matter what, always act as if you take up 30px more space on the bottom”. This ensures that all instances of that component (or class in CSS) will respect the explicit rule, for any other objects they’ll encounter throughout the design.

There is a quirk worth mentioning with margins known as ‘margin collapse’. This occurs when two block-level elements (like a div) have margins. For example, say the top one has a margin-bot: 30px and the bottom has margin-top: 50px, the resulting space between the elements will be the larger of the two, not their sum (o 50px, not 80px.) 

Apart from this, the explicit rule aligns well with the implicit intent.

Why design tools need to encourage more design options

After all of the examples in this article, I hope you can see that the mechanics of expressing implicit intent really depend on the design tool. Some will support fewer options, some will support many more. Code will probably support more than any design tool, but it’s inaccessible to most designers (Including me! I know my way around HTML and CSS but I don’t feel comfortable just coding in a code editor. I always prefer to use a UI as a helpful abstraction between myself and actual code).

This means that the tools that allow the most expressive and intelligent mechanics will be the ones that attract the designers that want to have the most expressive power. And with apps getting more and more dynamic and smart, screen sizes and viewports multiplying in numbers and content being more tailored to every user - I doubt designers can afford not to have the most expressive toolset at their fingertips. My prediction is that future-proof product design tools will be those that gravitate towards an ever-growing ‘coverage’ of the layout capabilities of code. They will perhaps never truly cover everything, but the tools that come the closest - will be the ones most worthy of our attention.

Helpful resources: The rabbit hole is deep (and empowering)

I hope this was an eye-opening, or at least somewhat thought-provoking read and if you’re interested, I encourage you to learn much more about the design options you have. Here’s a great list of resources for you to check out, at your own pace:

1. Christine Vallaure gives an excellent deep dive into Flexbox and CSS grid for designers.
   https://uxdesign.cc/why-ui-designers-should-understand-flexbox-and-css-grid-e236a9dec37a

2. Brad Frost, the man and the author of Atomic design, discusses grids as a concept between design and development.

3. Jen Simmons shows in many different video tutorials how to implement flexbox and css grid creatively
   https://www.youtube.com/@LayoutLand

4. The most incredible interactive guides for Flexbox and CSS by Josh Comeau
   https://www.joshwcomeau.com/css/interactive-guide-to-flexbox/
   https://www.joshwcomeau.com/css/interactive-guide-to-grid/

5. Webflow has one of the best academy video tutorials series out there:
   https://university.webflow.com/courses/ultimate-web-design-course

6. Framer has an academy series as well:
   https://www.framer.com/academy/

In this article, you’ll get a deep dive into why explicit design is where the future of our design environments is headed.

I’ll walk you through:

• What constitutes an interface design decision, beyond what most designers encounter inside vector design tools

• An easy and intuitive formula to help convey the decision we intend as designers, in a flexible, responsive and robust way

• How vector tools, code-like tools, and CSS itself allow us to express our desired intent

Let’s dive in. 

First: What is the difference between implicit intent and explicit design rules?

To answer this, it’s helpful to start with a question that every product designer can relate to: “How do I get these items over there, to align like this and respond like that to changes in screen width”.

Depending on the design tools you're using, you can find a solution in one of two ways. You can either design examples and variations that express implicit intent, which is common in vector-based tools like Sketch or Figma. Alternatively, you can declaratively design the rules from which infinite examples might arise, a capability primarily found in code or code-like tools such as Webflow, Framer, or Jux. This distinction highlights that while both approaches aim to fulfill your desired intent, code-like tools offer much more intelligent, responsive, and granular ways to express that intent through actual design rules. In the following sections, I’ll be walking through real and practical examples to show you exactly what I mean. 

Example: Box elements

Let’s say I want to space five objects out horizontally inside a box, and I want all of them to be spread out evenly from the left to the right side of the box. 

 If I describe the distance of each element from the top left corner I would be able to get my result visually, but I would be doing it by expressing a lot of specific information about each object.

The downside here is that it doesn’t scale. For example, if the amount of objects increases by one or decreases by one, all but the first item of information I used to describe my layout wouldn’t be relevant. If my box was to grow by 100px - same deal - I’d have to provide new measurements all over again.

The solution to this problem is getting to the broader, bigger picture intent of the action, like: “no matter the size of the box or the amount of elements, space them out evenly from left to right”. To make this intent true, you could use something like auto-layout (in the canvas tools), Flexbox in CSS, or code-like tools. 

For auto-layout, it would be: auto in the gap field

in Flexbox, it would be: justify: space-between;

In this case, no matter the width of the screen or the number of items inside the box - the implicit intent correlates perfectly with the explicit rule. And this is exactly how you go from static to dynamic and flexible design.

Direct manipulation vs thinking in rules

Plot twist: Designers love the ability to directly manipulate elements across the canvas, effortlessly moving, rotating, and placing them exactly where desired. This practice enables us to envision concrete examples of how the system might appear if all variables were fixed. From childhood, we're conditioned to perceive 'artboards' as static and finite, similar to posters. However, this mindset conflicts with the reality of designing products, which entails accommodating various screen resolutions, often with unpredictable amounts of content and variations.

So, how should these conflicting approaches be resolved?

Finding the middle ground

One solution is to let designers have a stage where they can play around, moving and resizing things until at least some key states of the system look decent. Only then would they move to the second stage, where they would try to find the best explicit rules for the result they reached while experimenting, this time across all the possible states.

The second approach would be to expect designers to slowly become so familiar with all the rule-based mechanics that they become intuitive enough for quick experimentation, completely bypassing the need to roam free. 

Both are two ends of the spectrum, with every designer intuitively finding the most comfortable place, somewhere in the middle.

Taking advantage of explicit rules

The good news is that with the right tools and application, it doesn’t have to be all or nothing. To understand how explicit rules can be beneficial, it’s helpful to know the kinds of explicit rules an interactive element might have. We can divide them into two categories:

• Self-related, independent visual properties: This can be things like color, border, text properties etc. They tend to not change and not be responsive to screens, resolutions and amount of user data

• Relationship-dependent properties: This can be things like placement inside a parent object, width, height, gap between objects etc. These are the properties this article is going to deal with.

To better explain how these types of properties work, I’ll narrow our focus to the web, showcasing examples across three creation environments:

1. Vector-based tools, such as Figma, Sketch, and Adobe XD, which most designers use for designing websites and web applications

2. Code-based design tools ike Framer, Webflow and Jux

3. CSS

Relationship-dependent: Width, height and their derivatives

It might be tempting to always specify precise and fixed measurements for the width and the height of elements. But it's probably only the right approach when you're certain the element won't change. For example, if we need the button to grow in width based on the length of its text field, we have to make the width ‘dynamic’.

Let’s look at how we’d do this in different tools.

In Figma: This would mean switching the button frame to have auto-layout and choosing ‘hug content’ for width. 

In Sketch: You’d have to set the button to have ‘smart layout’ with horizontal resizing.

In Jux and Webflow: You’d set the width field as ‘auto’.

In Framer: You’d have to select ‘fit content’ in the dropdown before the auto becomes accessible.

In CSS: You would make the width: auto

Note that the dynamic ‘undefined’ value for the width of the button is the explicit rule here that will work for all the infinite cases of text.

Four use cases that prove why explicit rules are important

Explicit rules, help you match input or commands with your implicit intent, the directive that will ensure applicability across various resolutions and specifications. Let’s look at four different situations, where the ability to design with greater flexibility, thanks to explicit rules for width and height, proves beneficial:

1. I want to have a cap on the width of my button: Let’s say you want to guardrail against a case where the labels on a button are completely out of your control and are user-dependent. Or for example, you don’t want the ‘OK’ button to be as short. In all three platforms, it would make sense to use min-width and max-width. Our implicit intent is now more nuanced: “have a width of however is needed, but not less than X and not more than Y.”

2. I want to place the button inside a modal, at the bottom: In this case, the implicit intent would be: “always stretch side to side, no matter what label it has”. To achieve this in Figma, you can use fill-container on the button, provided that the modal itself is set to auto-layout. In Jux, you can do it in a couple of ways, either by specifying 100% on the width of the button, or even better - selecting ‘flex’ for the modal and ‘stretch’ in the justify selection. In CSS, you can use percentage or flexbox.

3. I want to limit the modal from being taller than 80% of the height of the viewport: In this case, the implicit intent would be: “Grow height up to fit the content until you hit 80% of the viewport height and then stop”. Viewports come in many sizes. In Vector tools - you’re out of luck. There’s nothing you can specify as an explicit rule.. In code-like tools, you can specify an 80VH (viewport height) unit on the max-height of the modal, while leaving the height itself on auto.

4. I want the modal to be divided up into 3 columns with different ratios of their widths: Here, the implicit intent would be something like: “Divide into three columns, make the width of the first column 30%, the second 50% and the third 20% of the container width, and a 16px gap between them”. In this case the width of each column cannot be fixed, but it also cannot be ‘auto’.

   

   To specify an explicit rule in Sketch, Xd, or Figma, there’s really nothing you can do for that to work responsively. In Framer, for example, you can use a percentage unit on the width of each column by choosing relative in the dropdown. In Webflow, you can use Flexbox on the modal and specify the ratio using flex: grow number on the columns to adjust the ratios.

   

   In CSS and in both Framer and Webflow you can also use grid on the modal and specify each column's ratio using the fr unit (which stands for fraction), all while keeping the width of the modal on auto. Either of these solutions is a nuanced but powerful explicit design rule.

This concludes Part 1.

In Part 2 we will dive deeper and see how layout order, position, padding and margin also benefit from flexible and explicit design rules.

We've curated the finest pieces of written content by the most talented individuals, and we may be somewhat biased 🤓

Core, Semantic, and Specific tokens

TLDRed about streamlining product design communication in design & engineering teams, and the JUX approach to tokens types framework:
Core, Semantic, and Specific structure.

Read it here

Campfires & new ideas

discussed about a product workshop we ran, and noted that our channel "competition_and_inspiration" on Slack was the fifth most popular channel. He immediately attributed this to the comfort we at JUX feel around the "campfire" of sharing new concepts and upcoming features from tools and industries. Building better products? It all begins with collaboration and idea-sharing.

Check it out

An in-depth tokens guide

wrote a 2-part series about the real value of tokens in his publication .

Part 1, focuses on “Why tokens” and Part 2 dives into a more subjective prescription of how to conceptualize and model the work on tokens in a design system.

Part 1

Part 2

That’s a wrap, and it’s a button state of mind.

*Applied for early access?*

We're still testing our private alpha, and we’re onboarding people in batches every month.

If this email reminded you that you need a better design and dev experience in your team - simply reply and we will get you set up ASAP.

Hey believer. You recently asked for early access to Drimz, or maybe you're just a friend or relative. don't recall? Same ones who build a code-based design tool so product designers can design the actual, real product as it will be used in production.

We wanted to make it official - Bye-bye Drimz, Hello JUX.

And the best part? Our newly ultra-to-the-point website is live 🍾

4 reasons why we rebranded to JUX;

1. JUX, an abbreviation of Juxtaposition, is where you place two concepts, objects or personalities next to each other, thereby highlighting their innate differences and similarities. From our user feedback we also heard sentiments like "JUX? it's like juice!" and "Just UX! love it!"

2. Our logo is a button, the most known and used component e-v-e-r. A minor tweak in a simple button can have a massive impact on a business's growth.

3. The logo is also a reminder of the design and development relationship when creating a component, modifying and affecting it.

4. We embedded the JUX button's code into our caps' inner fabric. The color palette is based on four main colors used in engineers’ CLI daily. We currently have two types of caps - Type1 for engineers, Type2 for designers. Because they don't speak the same language. Get it?

*Our visual identity is an always-evolving WIP, like an open brand book. If you're interested in a comprehensive walkthrough about the process and how it's going, mail here or DM.

A three-second scrolling nostalgia for our old website:

Thank you drimz.io, we're grateful for you becoming a part of our lives. For being a part of the brand, storage, domain, and personality. It was a fantastic start ♡
And now, it’s a button state of mind.

*Applied for early access?*

We're still testing our private alpha, so we will onboard people in batches every month, starting this month.

If this email reminded you that you really need a better design and dev experience - simply reply and we will get you set up ASAP.