How we shipped support for screen flows thanks to Shape Up
Product Update

How we shipped support for screen flows thanks to Shape Up

Josef KettnerJosef Kettner

Our mission at Avocode has always been to help different stakeholders in the design process work more efficiently with design files - with a primary focus on front-end engineers.

The most common use case for Avocode is this:

  • designers need to focus on the design process so they share files with developers via Avocode so they wouldn’t have to export stuff for them
  • developers then come in and take all assets and specs directly from Avocode - this saves them time and helps them code faster

Most of the Avocode tools & features are built to help these two parties collaborate. Besides discussing things via comments, we always knew that developers also need to understand screen flow logic.

So back in 2018, we have built a simple Prototype player - any design file that contained some logic made via connections could be clickthrough also in Avocode. This was a nice little addition, but as developers ourselves, we understood we haven’t solved this fully.

To make it crystal clear, we had this...

... and we needed this:

Initially, our app has been built to display one design artboard at a time... and now we clearly need to display more - kind of like Sketch, Adobe XD, or Figma do.

To pull this off in the browser, that means that you need to parse uploaded design files, render them via C++, compile the result by Emscripten into machine-readable JavaScript code, and thanks to WebGL display the result. By the way, besides the parsing part, this is similar to how Figma renders design frames in the browser.

The design parsing is crucial to enable us to render all sorts of design file formats in the browser - like the afore-mentioned Sketch & Adobe XD.

Developing such technology isn’t a piece of cake. Luckily, we started building it years ago.

In early 2020 our rendering technology reached the state that it was not only displaying design artboards side by side in the browser (while making sure they remain sharp when the user pans or zooms), but it was working relatively fast. See below how our rendering works (for example, this is some Adobe XD artboard).

It was time to test it on a new project. Displaying (and editing) screen flows seemed like a great fit.

So what was stopping us?

Redefining our approach to product development with Shape Up

Although we had the technology ready, we had to design & build a completely new front-end and tweak many APIs. Based on previous product development experience, we always treat new feature development as experimental, meaning we don’t want to burn too much time on a project that doesn’t have an ensured value.

During the research phase of my "shaping" this project, I found out a few things worth mentioning here:

  • Roughly 60% of Sketch designers we have in Avocode already create screen flows in Sketch
  • Having one overview of all screens with links between them was important to 90% of all respondents (we got answers from ~550 people - both designers & developers)
  • 76% of respondents (sourced on forums and from our Blog subscribers) who are not currently using Avocode would switch to Avocode if it could create or edit screen flows

Our take on screen flows (in the MVP) was to make design flows fully accessible online - even without design tools. We wanted to enable:

  • overview of screen flows created in Figma, Adobe XD, and Sketch
  • editing of screen flows created in Figma, Adobe XD, and Sketch
  • creating new flows (from scratch) within Photoshop, Illustrator, Figma, Adobe XD, and Sketch files - i.e. all file formats we support in Avocode
  • presenting the flow as a simple clickable prototype in the browser (aka sharing via link)

Until the end of 2019, our process was a combination of Agile and Scrum. Most of our developers were dedicated to large-scale projects with only weekly sprint checks. When something was taking a little longer, it was simply tracked as "{task_name} Volume XY" - based on how many weeks it took.

From a business perspective - this is not a healthy approach because you don’t have clear deadlines.

So how could we change the culture and enforce fixed dates of release to innovate faster and ship more frequently? In a way that all team members would be motivated and wouldn’t feel pressured by strong directives?

Well, dear reader, I feel I may have found the solution. Have you ever heard of Shape Up?

Me neither... until the summer of 2019, when one of my friends sent me a book called Shape up by Basecamp. Spoiler alert - we implemented this methodology and it seems to do wonders for us.

So what is Shape Up about?

The Shape up really takes into account the preparation where an assigned person (called the Shaper) shapes (aka prepares) the concept of the feature in advance. Meaning, the Shaper will dive deep into the problematics in a few basic steps.

  1. Customer research, data analysis, surveys
  2. Draft solution
  3. Address rabbit holes
  4. List out no-gos

The key takeaway is that you'll spend 6-weeks on a project, and after that, you'll validate how it went. Whether the project turns out to be successful (read: you’ll ship something) or a failure, you spend "only" six weeks, not six months.

Excited by stumbling upon the Shape up as something new and unexplored, I estimated that using this process we could ship and validate the first version of prototyping in Avocode 1-2 Shape cycles, i.e. between 6-12 weeks.

TIP: If you want to know more about our path to adopting shape up, stay subscribed to our blog - the article is in progress!

So let’s see how we applied this "magic" process

In the first Dev cycle (read six weeks), we wanted to have an MVP, which would allow you to view artboards from one design file in the browser and enable you to drag connections from design elements (layers and layer groups).

This is a rough sketch of what I had in mind - connecting the Flow app with our current Design file manager.

Marker sketches - Showing the flow of the 2 apps.

On this project, I worked with a 5-person team consisting of 2 front-end developers, 1 backend developer, and 1 rendering developer. One of the front-end developers was also assigned the role of the lead developer. This person was responsible for the whole project since day one of the development cycle.

My role was to supervise and help answer possibly unclear specifications.

The first trade-off

The first technical challenge emerged right after the first couple of days, regarding the file formats. It is true that Avocode fully supports Sketch, Figma, Adobe XD, Photoshop, and Illustrator files.

  • However, Photoshop files - based on our data from over 8,000,000 designs, rarely have more than one artboard.
  • Also, our current support for the Illustrator file format doesn’t count with exact coordinates of Illustrator files, although we can render them correctly so the developer could inspect their layers. In short, adding the information about Illustrator artboard coordinates in our AI parser would bloat the scope of the project.
  • Lastly, Photoshop and Illustrator are less and less the go-to tools for UI design, which makes sense as these tools were never meant for UI design anyway.

So we reached an inevitable trade-off - to launch prototyping "only" with the support of Sketch, Figma, Adobe XD files.

Performance, performance, performance

The next challenge was putting our rendering technology under a performance test.

Displaying all artboards at once, even for big files containing lots of images. The overall performance had to be good, loading times had to be fast, zooming, and panning had to be smooth - no lagging or waiting times. No pressure, right?

  • The first optimization was to avoid processing duplicated images. We started to analyze the files during the opening, which helped us to identify duplicates of images, so then we only process the images once and not multiple times. This optimization helped us to cut the loading time and reduce the memory load.
  • Then we optimized image upload by implementing queues. In the beginning, we processed all images at once, which negatively affected the smoothness of the tool in the initial state; it lagged a lot. The queuing helped us achieve the desired smoothness, display enough for smooth user interactions, and process everything in the background.

Tip: Learn how we scale designs thanks to concurrent design rendering.

We also spent a lot of time discussing how to decrease loading times in the Present mode - namely, not having to load artboards one by one. For example, we thought of pre-loading fragments of particular artboards. However, it’s challenging since artboards can be connected completely randomly across the whole file.

Therefore, we decided not to do any "magic" and just hide the artboards we don’t need. In reality you'll always see the desired artboard in the flow, but the rest of the artboards will still be loaded and present, just hidden. By this solution, we've achieved smoothness and reduced loading time dramatically.

Going across the finish line

Six weeks were over. What did we end up with?

  • The first beta version with the ability to connect screens and layers in Sketch, Adobe XD, and Figma files.
  • We have built a new product feature on our new rendering technology and verified its potential.
  • Presenting clickable prototypes & sharing was not finished.

Overall - I would say quite a success. Internally, we decided that this project deserves to be kept alive, and we dedicated six more weeks before going live with it.

In 12 weeks we were able to ship Avocode Flow with:

  • 3 supported formats
  • Private and public sharing
  • Editing existing prototype connections (created in Sketch, Adobe XD, and Figma)
  • Option to open and edit designs in the Avocode Flow from Avocode file manager
  • Mobile/desktop friendly Present mode for all clickable prototypes (still needs some love though)

What’s the added value for our users?

Besides helping developers understand flow logic in design files, we also created a tool for UX specialists and other stakeholders who need to create simple clickable flows and diagrams.

What's next?

Before we start adding new features, we need to hear from you. I’ll welcome any feedback at

Did you like this article? Spread the word!

What is Avocode?

It’s an all-in-one tool for teams that want to code and collaborate on UI design files 2x faster.