Dynamic grid — How to solve UX problems with code

When we converted our organization’s experiences to responsive design, we had a lot of issues working globally and at scale. We already had a mature product, and it’s not a matter of just fitting the design to a desktop or tablet. We wanted to make the experience translate to the desktop seamlessly.

Unfortunately, Figma has its limitations when working on responsive design, let alone simultaneously converting multiple experiences to responsive design. And adding to that, communicating design decisions in a large corporation at a global scale.

To solve this issue, I created a few responsive components that help designers create responsive layouts with simple rules — No need for multiple canvases for every breakpoint.

I left Figma and started creating POCs with code

While CSS & JavaScript have many features for handling responsive design, Figma only has a few, and even those are limited. Communicating and creating flexible solutions can be challenging on Figma and sometimes even feel impossible.

A simple Figma file becomes a series of canvases for every breakpoint, with notes on every change. Files like these are hard to create, maintain, and communicate over time.

Instead of forcing Figma to do what it can’t, I started making fast proof-of-concept components that the design team could see, discuss, and change quickly on the go.

One example that reflects this the most is the Dynamic Grid (aka ✨Magic Grid✨) component.

What’s a Dynamic Grid, you ask?

Dynamic Grid is a layout component for catalog layouts that, with a few rules (requiring only one), can dynamically calculate the grid based on its width.

What are the rules we came up with for the grid?

Now, we can solidify the MVP rules. We decided that these features fit our needs and cover most of our use cases.

First of all, we need a minimum width for the items inside the grid. With this basic rule, developers can easily add components. The grid will figure out how to scale the columns without reaching that minimum.

Changing the minimum width will automatically change the number of columns for every screen size

Maximum rows can limit the number of rows designers want the user to see on the screen. It can help by increasing the number of featured items per page for different categories.

Maximum rows can help us limit the number of items visible in the page

Maximum columns can help designers keep the minimum width small but avoid clutter by limiting the number of items per row.

Changing the maximum amount of columns does not effect the minimum width, only limits the number of items in a row

It’s also possible to set a division rule for the number of columns. That way, designers can keep the number of columns divided by two, three, four, etc.

Setting the division of columns will let us put a certain item count that will look symmetrical on every width

Making the grid scrollable is also possible, opening up more options.

Example of how a layout can be scrollable with a simple change of a property

I created this grid with a simple design to easily allow adding features over time.

And there are many more sub-rules, configurations, and accessibility features, to suit the needs of different teams.

How did you come up with the rules?

I started by mapping the global teams’ different products and needs and creating a few live components. I made changes and fast iterations while consulting the design system team and stakeholders.

At this stage, it’s crucial not to get hung up on making the component perfect but to make it work. We can make changes fast, even during feedback sessions, by creating flexible elements.

Next, I mapped what we can get straight from CSS and what needs to be programmable. I will probably do a full tech breakdown of the grid in the future. In short, I used the CSS grid’s auto-fit and auto-fill features with some JavaScript magic to calculate columns for more custom cases.

Here are a few tips for working fast on a global scale

Make it shareable

Find a platform that works for you. Whether it’s StoryBook with a live environment, StackBlitz, or CodePen — find the best way to share your live POC with as many stakeholders as possible.

Share it with everyone

Sharing with as many people as possible can help us find blind spots and use cases. Of course, we must share it with people with design, product, and development perspectives. Even if you don’t make all the adjustments, you can prepare for them.

Make it work fast, then make it perfect

It applies to everything we develop, especially if there’s no mock-up. For the first stages of the POC, just make all the features work. Show and iterate. See if you can make it all work, then start preparing it to fit the high standards for a global component library.

Before implementing it into a component library, take it to the road

Try it on your use cases in production. See how it works. Deploy it in some areas. Run tests on it. We can’t see all our problems in a vacuum.

And it’s always nice to avoid changes that break the global design library 😅

What’s next?

We develop more features into the component. For example, I built a carousel component based on the grid scroll features. It also reduced the time we need to prototype breakpoints drastically.

And finally, there’s a need to communicate this kind of component better with Figma templates so that designers and developers can work even better.

As product designers, we need a basic technical understanding of the platform we are working on. Learning the constraints and flexibility of our platforms can help us become better problem solvers and feature creators. The Dynamic Grid component is just one solution, but other creative solutions can emerge when designers explore beyond the boundaries and limitations of their tools.