How could the design industry innovate faster?

The most frequent question I get as a designer: What is the key ingredient to great design? After 10 years in this industry, I don’t recall working on a successful project that I would design from top to bottom. That’s why I always respond that the magic ingredient is collaboration.

I think that developers have found out that collaboration is vital early on — before UI designers. The complexity of code has first required a second pair of eyes for a code review and then versioning systems for simultaneous development.

As the screen design industry becomes more complicated (responsiveness, interactions…) designers are adopting developer practices like smart components, or versioning. With all the new design roles springing up, I believe that the roles of the designer and the front-end developer will soon intersect and blur completely because everyone will be more involved in various parts of the process of launching a new screen (or digital if you like) product, service or a presentation.

The roles of the designer and the front-end developer will soon intersect and blur completely.

Unfortunately, while there is an evident need for collective work the design tool market doesn’t respond accordingly. If you critically assess all the tools for UI design these days, you’ll find out that their feature set is pretty much the same. Every design tool builds a “new” rapid prototyping, hand-off, or versioning feature from scratch. These design companies have the top talents in graphics development, and yet they all work closed in their silos instead really moving forward together.

The design tool market doesn’t respond accordingly.

In turn, designers (and other stakeholders) have to make the hard choice which operating system to run and which tool to migrate to, since none of them are fully cross-platform or compatible with all of the existing ones.

Instead of focusing on new problems that the design space is facing (like design semantics and recognition of design components), the top teams of our market are fiercely competing for users by marketing similar feature sets in a different fashion.

But hang on a sec.

This space has never been about tools. I believe that it’s always been about the people and the eventual outcome the “it” that creative folks try to shape, polish and launch out there. I think of tools as the vehicle that drives this process. If you take this up a notch, I would say that tools actually shouldn’t matter. What do I mean by that? If tools were so smooth that you wouldn’t really notice them while using them, only then you could only focus on the “it” that you’re trying to bring to life.

Sounds dreamy right?

I know. The reality is different. Every new tool promises to streamline on/or all of these general workflows: designer → designers, designers → stakeholder, designer → developer.

So why hasn’t any of them succeeded yet?

I think one of the reasons could be that the whole space lacks a universal standard. One format that would be flexible enough to have a representation for everything that can appear in any of the existing and widely used design tools. Something like a PDF, but one that you can work with — you can look at it, you can edit it, and you can turn it into code easily.

The whole space lacks a universal standard.

It turns out that we have built something that pretty much matches this description. Our flagship product — Avocode — is a tool to help anyone access and inspect any design file without being dependent on current design tools.

The technology that makes this possible is a standardized app-independent format that we call Octopus and our rendering engine called Monroe.

• Octopus is a universal design format, that allows us to do just what I described in the earlier paragraph: currently it has a representation for everything that can appear in Sketch, Photoshop, Adobe XD, Illustrator (and soon Figma, InVision Studio, and perhaps even Framer X) and yet it doesn’t need any of these tools to make the actual design file contents accessible to the user.
• Monroe is a universal rendering engine that takes care of recreating the design. It’s written in C++ and OpenGL and it runs on every operating system, even on the web thanks to WebAssembly. It takes any design file translated to the Octopus format and displays it exactly as the original. Technically speaking it’s an orchestrated system of applications — each responsible for drawing shapes, applying effects, creating text and more. It pretty much does in 2D what the Unity rendering engine does in 3D.

A representation for everything that can appear in Sketch, Photoshop, XD, Illustrator (and soon Figma & inVision Studio).

Both Octopus and Monroe are currently closed in the ecosystem of the Avocode platform, so you can explore their potential by importing and opening a design file, inspecting all of its layers without any preparations, or by converting a PSD design to Sketch via our free service. Editing is not yet possible.

Why am I telling you all this?

Well, I am not sure that we should build another (yet cross-platform) design tool, that would make design editing possible, even though we have the technology to do so. There are already plenty of good design tools. I have something different in mind.

What if we opened the Octopus format to developers and made Monroe rendering accessible to startups and enterprises?

I am not sure that we should build another (yet cross-platform) design tool.

The opportunities this would bring are quite significant:

Octopus format development opportunities:

• Current design tools could save design files in a standardized format that could be opened in any other design tool.
• Current design tools could open different design files formats without having to develop their custom converters.
• New tools that are trying to improve our industry wouldn’t have to build a new design format but could use a standardized one.
• Other representations could be added to the format — such as semantic data about group layers and other objects so the generation of production-ready components (and not just styles) would be a piece of cake (something like AirbnbEng is working on).

Monroe rendering development opportunities:

• New tools wouldn’t have to build a new design rendering engine from scratch and could use an already working infrastructure.
• New tools could focus on developing features for better versioning, better design file management, better showcase, and feedback gathering.
• Enterprise businesses that need to import and display design files could easily do that without having to develop a custom technology or show error states — e.g. when you want to display a crystal sharp preview of an Adobe XD or Sketch file in Dropbox).

It’s quite interesting, perhaps even entertaining, that we have built a somewhat niche product for designers and developers, but for it to work properly we have developed a robust technology with a much bigger potential and a wide range of use cases.

So today, I'd like to show our initiative on how to solve this problem that we've been feeling for a long time. I'm happy to announce Avocode SDK — Software Development Kit made from our design parsers, universal design format and cross-platform graphics engine — available to partners who need to innovate faster. In other words, this technology can easily power all the ideas I mentioned above.

To help us decide better how to utilitize this technology for the digital industry, I’d love to hear your thoughts.

Can you sense the potential of this technology?

Can you think of new ways how this could be useful? Either for your workflow or for a product that you’re building?

Feel free to let me know in the comments or at vu@avocode.com. 🥑

Avocode is the first cross-platform design hand-off tool for teams that are building next-generation Web, iOS, & Android projects.