Guía de ClaudeNivel 3 · AutomatizarLevel 3 · Automating

Pedirle criterio de diseñoAsking it for design judgment

Una skill con las pautas de Apple como vara, y lo que encontró en una app mía mirada en un celular.A skill that uses Apple's guidelines as the yardstick, and what it found in one of my apps viewed on a phone.

Claude diseña pantallas que funcionan en mi monitor y se rompen en el celular, y la razón es simple: nadie le dijo contra qué compararlas. Si le pedís “mejorá el diseño”, mejora lo que se le ocurre. Si le das una vara, mide.

La vara

Instalé una skill ajena, apple-design, solo en la carpeta de ese proyecto. Trae 123 páginas de las Human Interface Guidelines de Apple (las pautas con las que Apple diseña sus pantallas) y una regla que me gusta: antes de opinar, lee la pauta, y cada observación cita el archivo y el apartado de donde sale. Sin cita, es opinión, y opinión ya tengo yo (de sobra).

La otra regla es de tamaño: en cada revisión carga entre 8 y 12 de esas páginas, siempre las de accesibilidad, diagramación, tipografía y color, más las de la plataforma. No se lee el manual entero cada vez, que es justo lo que le pido a todo lo demás en cómo se gasta la cuota.

Lo que encontró

La probé con una app para la carrera que armé, abierta a 375 píxeles de ancho, que es un celular chico. Esto salió:

  • Nueve pestañas arriba que no entraban y desbordaban hacia los costados.
  • Cosas para tocar de 34, 36 y hasta 20 píxeles (los enlaces). La pauta pide 44. Los de 20 no los acertaba ni yo, que los había puesto ahí.
  • El cartel de cookies ocupaba un 20 % de la pantalla, siempre, tapando justo lo que había que leer.

Lo arreglamos así: las pestañas pasaron a una barra inferior, que es donde el pulgar llega; todo lo tocable subió a 44 píxeles; el cartel de cookies se achicó; y en pantallas grandes se aprovechó el ancho en lugar de dejar una columna angosta en el medio. Le había pedido algo mucho más vago: “revisá la app, proponé una lista de cambios y mostrame un prototipo”. Lo único que agregué en el medio fue “ojo, que no es solo para celular”, y por eso la versión de escritorio también salió ganando.

La salvedad

Todo esto lo vimos en un navegador con el ancho achicado. No lo probé en un celular físico, y un celular de verdad tiene un pulgar, una pantalla sucia y un sol que pega de costado. Tomalo como una primera pasada y no como una aprobación. La accesibilidad tiene su propia tarjeta porque ahí la vara es otra.

Cuándo sirve y cuándo no

Sirve cuando ya hay algo hecho y querés una crítica con fuente. No sirve para decidir qué construir; eso va antes, en la entrevista. Y no reemplaza a una persona usándolo. Si un amigo tarda diez segundos en encontrar un botón, ese dato vale más que cualquier cita de pauta.

El prompt

Revisá el diseño de esta app como lo haría la skill apple-design, mirándola a 375 píxeles de ancho. Elegí entre 8 y 12 archivos que definan la interfaz y decime cuáles elegiste. Para cada problema, citá la pauta de la que sale, el archivo y la línea, y qué cambiarías. Ordenalos por cuánto estorban a quien la usa. Aclará qué cosas no pudiste verificar sin un celular real. Proponé los cambios como diff y no guardes nada sin que lo apruebe.

Claude designs screens that work on my monitor and fall apart on a phone, and the reason is simple: nobody told it what to measure them against. If you ask it to “improve the design,” it improves whatever occurs to it. If you give it a yardstick, it measures.

The yardstick

I installed someone else's skill, apple-design, only in that project's folder. It brings 123 pages of Apple's Human Interface Guidelines (the rules Apple designs its own screens by) and a rule I like: before giving an opinion, it reads the guideline, and every observation cites the file and the section it comes from. No citation, it's an opinion, and I've got plenty of those (more than enough).

The other rule is about size: in each review it loads between 8 and 12 of those pages, always the ones on accessibility, layout, typography and color, plus the platform's own. It doesn't read the whole manual every time, which is exactly what I ask of everything else in how the quota gets spent.

What it found

I tried it on an app I built for my degree, opened at 375 pixels wide, which is a small phone. This is what came out:

  • Nine tabs along the top that didn't fit and spilled off to the sides.
  • Tap targets of 34, 36 and even 20 pixels (the links). The guideline asks for 44. I couldn't hit the 20-pixel ones myself, and I'd put them there.
  • The cookie banner took up 20% of the screen, always, covering exactly what you needed to read.

We fixed it like this: the tabs moved to a bottom bar, which is where the thumb reaches; everything tappable went up to 44 pixels; the cookie banner got smaller; and on large screens the width got used instead of leaving a narrow column in the middle. What I'd asked for was much vaguer: “review the app, propose a list of changes and show me a prototype.” The only thing I added along the way was “careful, it's not just for phones,” and that's why the desktop version came out ahead too.

The caveat

We saw all this in a browser with the width squeezed. I didn't test it on a physical phone, and a real phone comes with a thumb, a smudged screen and sun hitting it from the side. Take it as a first pass, not as an approval. Accessibility has its own card because the yardstick there is a different one.

When it helps and when it doesn't

It helps when something already exists and you want a critique with a source. It doesn't help to decide what to build; that comes earlier, in the interview. And it doesn't replace a person using the thing. If a friend takes ten seconds to find a button, that fact is worth more than any guideline citation.

The prompt

Review this app's design the way the apple-design skill would, looking at it at 375 pixels wide. Pick between 8 and 12 files that define the interface and tell me which ones you picked. For each problem, cite the guideline it comes from, the file and the line, and say what you'd change. Order them by how much they get in the user's way. Say what you couldn't verify without a real phone. Propose the changes as a diff and don't save anything until I approve it.