Reshaping the design process with code – Part 1

As a part of several posts on how we are reshaping the design process with code, we will begin with an introduction to how it all began.

At Layerise, we are on a mission to ensure that everyone in the team can and is empowered to design. Design should not be produced in a vacuum and it should be a constant iterative process without an end. — In fact, there is no such thing as a perfect design since the demand for new experience, new technology and digital standards keep evolving.

To comply with the need for fluid and team broad design methods, we have decided to create a new design process from the ground up. But how do you bring together the whole team to prototype and participate in the design process?

The end is the beginning

To understand how we design we conducted an internal exercise, an exercise based on presumptions. We needed to understand what design is and how we make design. Here are some of the interesting presumptions the team came up with:

Designers don't code.

There too many steps from idea to delivery.

Responsive design is cumbersome.

UX can't be accurately tracked.

Too much software is needed in the process.

This is just a few of many interesting presumptions. Next step was to dive into these presumptions and try to understand them.

One presumption kept being brought up. Designers don't code. A never ending question in the design community and among scholars. But in our case it became a very interesting topic, as we all had challenges with not being able to implement our own design. Emulating the design implementation in a graphical editor just seems to be a slow and tedious process and the design implementation was always impacted by the tools used, the reviews and resources.

Code seemed to be the goal, but an untouchable goal. When design was delivered the process stopped and a new sprint began. The only iterative process was when that particular area/feature had to be changed. So we began to play with the idea that we could code. What did that mean for the design process?

We will be able to do interactive design.

We could deliver responsive components.

We could work with applicable animation and interaction.

We could setup tracking and measurements per component.

We could have one source of truth from design to implementation.

We could limit the amount of steps. No more handoff!

We could invite more team members to participate and leave design feedback.

While this sure seems like a dream process we where still interested in understanding why so few designers had jumped into coding. We invited some of our developers to participate in the discussion. The answer was as you probably anticipated, starting to learn code felt overwelming.

However, a recent technology and DX (developer experience) leap has allowed designers to jump into code easier than ever.

Frameworks like React and ideas like CSS-in-JS have many concepts we know from the design world. Components and props are similar to Sketch's symbols and overrides.

That didn't sound that scary, we were intrigued by this. In the next several posts we will dive into how we went from a rigid waterfall design process to a fluid iterative process. How we managed to become multi-disciplinary and what it means for the design team and the design output.

This is the end of part 1, click the card below to read second part of how Layerise's utilize code in their design process.