How to wear the Designer and Builder hats at the same time

In Part 17 of my project to build the biggest online archive of the Rotis font, I explore why and how the creation of digital products is not a linear process

When I started building rotisarchive.com, the idea for the website was so straightforward that I didn’t even design a static mock-up first.

My first post showed that it consisted of just 4 pages; a homepage containing an infinite scroll grid of square images with captions, and another 3 pages for media categories; Branding, Signage, and Print.

The website building tool I was using, Framer, worked so similarly to the industry-standard static design tool, Figma, that it was easy to dive straight in and build a functioning website from day one.

(Yes, these tools have similar-ish names. I’ll do my best not to mix them up!)

As the project developed, however, a couple of things happened.

First, my confidence in using Framer grew. I started experimenting with its more advanced features.

And secondly, I accumulated and implemented a backlog of ideas including those that came to mind and also those that others kindly suggested. The website grew from its initial 4 pages to 18. And there were more still to come.

The problem

Framer isn’t as forgiving as Figma when it comes to creating a messy canvas of design experiments. And as my website scaled, I found myself unable to quickly play around with a concept without breaking a major piece of the website.

For example, extending the new nav bar design from my last newsletter to a Mobile layout proved trickier than I anticipated. I needed to quickly experiment with some solutions without breaking the existing tried-and-tested components.

But the app was forcing me to make design decisions before I was ready. And so, this week I decided to stop working directly in Framer. I recreated the design in Figma and picked up my experiments there.

The obvious question

A question you might ask is “Well, isn’t it obvious that you should always design before you build?”

But that would be suggesting that the process is more linear than it actually is.

To make this more tangible, you might say that the workflow between Figma and Framer echos the workflow between a Designer and Developer in a product team.

The Designer needs to rapidly throw ideas around on a canvas and converge on a final design, and the Developer needs to take that design and turn it into a well-structured and robust website.

That sounds like a linear process, where a designer takes their design and ‘throws it over the wall’ to a developer without ever saying a word to them.

The risk

Even if you meticulously document every single button and animation in your design, it’s almost impossible to identify upfront every single assumption you’re making; assumptions about the Developer’s understanding of your design, but also assumptions about your understanding of what the Developer can build.

That’s why these specialists need to constantly communicate with each other. Not to simply ‘keep each other up to date’, but to do the harder work of identifying and validating their assumptions with each other.

Now we circle back to my project.

The solution

Like any tool, Framer has its technical niggles and limitations. There’s no point spending time optimising a mock-up in Figma if it turns out it can’t be built.

So, while I’ll be designing in Figma before building in Framer, I’ll need to keep both apps open side by side from now on.

And what about you? Hit ‘Reply’ and tell me about the experiences you’ve had being both designer and builder and how you’ve hopped between different tools to realise your vision.

Thanks for reading and have a nice week (Spring is here!) 🌻