In keeping up with what other people are doing with Figma (like improving developer workflow with the hand-off tools and atomic component libraries), we are feeling comfortable with our process while making small updates here and there.

Wait. Comfortable? That’s no good. What to do?

What if there was a paradigm shift that Figma, as a tool, is secretly waiting to be used to jumpstart? What if we could completely upend the way we work as a team so significantly that our design quality and productivity would seem impossibly high? What if there was a paradigm shift like this that already took place and continues to dominate innovation in manufacturing?

Turns out, there was, and we think there is. Commonly called “Lean” this process refers to a manufacturing philosophy and methodology developed by Toyota since the company was founded about 80 years ago. There have been attempts to make use of this methodology in software and product development for decades but there are some software and skillset limitations that have been in the way.

The agile development process has provided us with a near-miss in many cases. We still typically work with a waterfall methodology to get from user need and user flow to wireframes and to ready-for-development comps. This has been a stable and well-worn approach that gives UX and UI designers time to button up their designs for consumption by the developer.

What’s so bad about this approach, then? Well…

1. It’s comfortable! It’s very difficult to improve if you’re too comfortable.

2. There is waste built into waiting.

3. There will always be problems hidden in the finished work if it’s not being put through some qualifying process immediately and continuously.

Modern design software like Figma has provided tools to assuage the creeping wastes and inefficiencies of the design process but perhaps we are not using it to its full potential. What we are looking for with the lean approach is “flow”, “pull”, and “value added.”

How might we address the everyday risks inherent to the design process status quo with a tool like Figma?

Too comfortable?

‍ Shake up the transparency to uncover what is plaguing your process that would otherwise go undiscovered. Get everyone on the project working in the same file at the same time. Together. Use Pages to keep things organized. (value added)

Waiting to work?

‍ Arrange the output of the design process for it to be consumed most efficiently by development, or the next team member down stream. Designs should be delivered from atomic components up, just as they will be consumed by dev. (pull)

Surprising the developer?

Why does the developer have to be surprised by incomplete designs, or under-considered use of design components, or missing button states and destinations that so easily occur when working on large projects? Developers should have early access to the design. Designers should have early access to UX, and round and round. (flow)

Let’s see how we can start to set this up:

One of Figma’s most exciting features is live collaboration. We can take advantage of this by creating one project file in which everyone is building their respective parts. We will have individual pages dedicated to wireframes, design system, full comps, and design components. The goal of each of these pages is to produce a consumable for the next team member and their respective page in Figma.

Starting with the developer, we can work backwards to understand that they first need the design components and then full comps to start development. The designer needs wireframes and wire components to build these deliverables, and the UX designer needs to understand the user experience (in this case a customer funnel) in order to create what the designer needs.Working forward again, we know we will need to design the customer funnel first, from which we can begin to design wireframes. To avoid setting ourselves up for a linear information flow, the entire team should understand the customer funnel. The benefits of this should start to show themselves in the next steps.

It may sound like we’re setting ourselves up for a waterfall process, but that’s where the next piece comes in.

We know that there will need to be certain components no matter what the customer funnel is, right? Every web design has headlines, paragraphs, colors, images, links, CTAs, etc. The UI designer can start with building a palette of these design components and making them into Figma components.

Designers might like to do this while putting the design components together in comps to see how they work with one another and in context. Have the designer start to do this with the understanding of both the customer funnel goals and also the design deliverables for the developer.

Because they are in the same file, it will be easy for the UX designer and the UI designer to see and take inspiration from each other's work. Essentially, it’s live collaboration across disciplines.

It’s okay if it is the same designer doing both. That just means they will do a bit of back and forth and may not need the same formality in the UX deliverables. ‍

So from the very beginning of a project, you should have deliverables or consumables start to take shape very quickly. A library of parts will start to crystalize from brand, design, and UX components into a design system.

There is sure to be some friction when changing over to such a high transparency and demanding process, which actually one of the biggest benefits of this approach. Many points of friction that are uncovered as a result of working this way are the same points of friction you already have in your process. Now, the impetus to make improvements is much stronger.

Approaching the design process this way is something Edgar Allan is actively working on. There will be a lot of learning as we go along, and if we do it correctly, the learning won’t stop. So, consider this the first installment and keep an eye on what’s next in a series of lean production in web design.

‍