Raúl Álvarez González
AI Fluency Ladder 2026

The context

Viooh’s Design Team has been operating for the last couple of years with a tight ratio of Designers to PMs. As a designer, I’ve worked with one—ocasionally two—PM at a time. Our team has to ‘feed’ at least three. In a classic ways of working, this has slowed down discovery. PMs frequently would have to wait for one of the designers to get some capacity to look at some early concepts for the features they were working on. This work was also time consuming, requiring precise mock ups of tens of screens for a single feature that then had to be built into a prototype if some testing was needed.

Vibe-coding as a design tool: Our first breakthrough

During the first half of 2025 we started testing vibe coding tools like Lovable of v0—Figma eventually also launched ‘Make’—in an aim to use AI to upgrade our ways of working. Now the designer could just prompt an AI to produce a living artefact that expressed the designs that they had in mind. Already faster than mocking up all those screens and ready to be played with in testing. This even transformed the product team, which onboarded the PMs in the same tool so now they could start building these prototypes directly.

Although a bit lengthy, this video captures how we would go about using atomic design to control every bit of the design and interaction of our prototypes.

Pause and synthesis

It comes a moment in which simply “using more AI” is not enough. We had to understand how AI can be used and how we were using in order to present new opportunities for more meaningful transformation. The result of this was our AI fluency ladder. Now we could map where we were and what would entail climbing up the ladder.

01

AI as a better Google

Asking instead of searching — you still do all the work yourself.

02

AI to build outputs

A vibe-coded prototype

We were here
03

AI as infrastructure

Skills and agents so the designer is no longer a blocker

04

AI as labour

When we move from people to AI operating that infrastructure

A new altitude for the design team

For the Design team to operate at this new altitude a shift in mindset was needed. Thinking in terms of design infrastructure means no longer living attached to the production of deliverables. From pushing pixels in a specific solution to creating the skills and agents that will enable anyone in the company to explore solutions with a good enough design.

Despite this, designers will still design. We’ve just cleared a lot of the time in the discovery phase so now they can focus on elevating what really works. Our infrastructure should create some 6/10 or 7/10, so our designers can focus on elevating whatever works to a 10/10 or 11/10.

A new set of deliverables

Our first contribution to this new reality was an auto-improving DESIGN.md and a brand new design-exploration skill.

Designing in 2026
Our new file format

DESIGN.md

This is Google’s standard to explain a Design System to an LLM. AI helped us creating a first draft based off our production code. Since then, we’ve automated how to imporve this file so we get results as accurate as possible with as few visual isntructions as possible:

  1. We’ve defined a benchmark around the key screens in our production version. The benchamrk has a spec.md file with a functional description of the target screen, devoid of any visual detail or decssion; and a truth.png with a screenshot of the production screen.
  2. With every new version, we pass give a clean instance of the LLM the task of building spec.md with the only help of DESIGN.md—no other context is provided—.
  3. Claude can then compare the output, in html format against truth.png. It will identify the divergences and write the fixes needed in a report.
  4. These fixes are then filed in the issue tracking of the project in GitHub. Claude can then apply all the fixes and run the benchmark again. In just a couple of loops we’ve already goot our DESIGN.md to a point that our PMs are happy to use.

With this, the PMs end up with a tool that can already translate functional requirements into our design language with no visual instructions.

design-exploration skill

Next to that, we also provide a skill that will take the progress on a feature’s discovery and propose three diverging directions that the feature could take, simplifying decission-making for the PM. The exploration is generated in an html file which can be shared and opened without needing a new proprietary software. Designers can also review these artifacts and do a critique on their designs. Critique of Claude’s work, not the PM. The LLM can then distill this feedback into a new version of the skill which gets distributed to all the PMs.

PMs are no longer blocked by the designers while these can gradually improve this infrastructure in a transparent fashion.