Stats
Actions
Tags
From ux-research-toolkit
Advises on what feedback to expect (and NOT expect) from user research sessions based on the fidelity level of the artifact being tested (sketches, wireframes, high-fi mockups, clickable prototypes, coded builds). Use when the user asks "what should I test", "fidelity level", "what feedback to expect", "nivel de fidelidad", "que esperar del testing", "testing wireframes vs prototype", "/fidelity-guide", or is unsure whether an artifact is ready to show users. Based on Lean UX (Jeff Gothelf, O'Reilly 2013), cap. 5 — "The Fidelity Sweet Spot".
How this skill is triggered — by the user, by Claude, or both
Slash command
/ux-research-toolkit:fidelity-guideThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Ayuda a decidir **qué feedback esperar** de una sesión de research según el nivel de
Ayuda a decidir qué feedback esperar de una sesión de research según el nivel de fidelidad del artefacto. Evita errores comunes como testear branding con sketches (demasiado pronto) o cuestionar la IA con un build coded (demasiado tarde).
Basado en Lean UX (Jeff Gothelf, O'Reilly 2013), cap. 5.
Contenido en español. Términos de diseño UX en formato "español (English)" la primera vez que aparecen.
Esta skill NO produce archivos por default — es consultiva. Si el usuario pide registro de la decisión tomada, puede generar:
./docs/ux-research/fidelity-decisions/YYYY-MM-DD-[topic].md
Invocar esta skill ANTES de un testing day (jueves en research-cadence) cuando
hay dudas sobre qué artefacto mostrar o qué esperar de la sesión.
Qué es: Dibujos a mano, crudos, en papel o tablet. Sin colores, sin texto final, sin layout definitivo. Hechos en minutos.
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: Conversación open-ended tipo "¿qué ves acá? ¿qué harías?"
Cuándo usar: Fase temprana de divergencia. Después de un Design Studio.
Mal uso común: Mostrar sketch y preguntar "¿te gusta el diseño?" — no hay diseño todavía, la pregunta es incoherente.
Qué es: Layouts con boxes, placeholders, navegación definida, pero sin visual design. Blanco y negro o grises. Sin clicks funcionales.
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: Walkthrough guiado. Usuario explica qué ve, qué clickaría, por qué. Moderador puede simular navegación mostrando el siguiente wireframe.
Cuándo usar: Después de validar el concepto con sketches. Antes de invertir en visual design.
Mal uso común: Dejar el wireframe con Lorem Ipsum y preguntar si entienden el contenido. El copy debe ser placeholder realista, no abstracto.
Qué es: Diseño visual completo — colores, tipografía, iconografía, sombras, espaciado. Pero NO es clickeable — son imágenes.
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: Preference testing, 5-second test, first-click test. Mostrar la imagen 5 segundos, preguntar qué recuerda.
Cuándo usar: Validar visual design ANTES de invertir en prototipo clickeable o código.
Mal uso común: Testear usabilidad con mockups no-clickeables. Si necesitás saber si pueden navegar, usá Nivel 4+.
Qué es: Mockups conectados con transiciones. El usuario puede clickar y navegar entre pantallas. Sin lógica de negocio real — las transiciones son predefinidas.
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: Task-based usability testing. "Querés comprar un café — mostrame cómo lo harías." Cronometrar tareas, anotar fricciones.
Cuándo usar: Antes de escribir código. Para validar que el flow funciona antes de comprometer dev time.
Mal uso común: Testear comportamiento con data real. Si necesitás saber cómo se comporta con 10,000 items vs. 2 items, usá Nivel 5+.
Qué es: Código real, pero:
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: Usability testing completo + think-aloud protocol. El usuario usa el prototype como si fuera su app normal.
Cuándo usar: Validar la UX antes de conectar la API real y comprometer inversión de backend.
Mal uso común: Testear con equipo interno solamente. Los colegas saben demasiado sobre el producto y ocultan problemas reales.
Qué es: El producto real o cercano al real. Data real de usuarios reales, integraciones reales, deploy completo.
Qué feedback SÍ esperar:
Qué feedback NO esperar:
Método de test ideal: A/B testing, cohort analysis, funnel analysis, session recordings (ej. PostHog), NPS / CSAT surveys, customer interviews post-uso.
Cuándo usar: Después de validar con niveles 4-5. Para optimizar lo que ya funciona, no para descubrir si funciona.
Mal uso común: Hacer user testing tipo "¿te gusta el nuevo diseño?" con producto live. A esa altura ya no deberías preguntar opinión subjetiva — deberías medir comportamiento real.
¿Qué querés aprender? → Nivel recomendado
¿La idea/concepto tiene sentido? → Nivel 1 (sketches)
¿La estructura/navegación funciona? → Nivel 2 (wireframes)
¿El visual design comunica? → Nivel 3 (mockups)
¿Pueden completar tareas end-to-end? → Nivel 4 (clickable prototype)
¿Las microinteracciones funcionan? → Nivel 5 (coded, mock data)
¿Hay traction / conversion? → Nivel 6 (producción + analytics)
Regla de oro: Usá la fidelidad MÁS BAJA que responda tu pregunta de investigación. Cuanto mayor la fidelidad, mayor el costo de cambio y menor la apertura del usuario a feedback radical (asumen que "ya está decidido").
Regardless del nivel, siempre setear expectativas con el participante:
"Esto es una maqueta temprana — nada está clickeable. Quiero entender qué pensás sobre el concepto y la estructura. Si algo parece 'incompleto', es intencional — voy a tomar nota de lo que falta según tu criterio."
"Esto es un prototipo — las cosas parecen reales pero algunas interacciones están limitadas. Si clickás algo que no responde, no es bug, es que todavía no está prototipado — anotamos eso como feedback."
"Esto es un producto real (o casi real). Usalo como si fuera tu aplicación normal. Si encontrás algo que no funciona, es un bug real que queremos arreglar. Pensá en voz alta mientras lo usás."
Error común: nivel de fidelidad del artefacto NO matchea la pregunta de investigación.
| Pregunta | Artefacto INCORRECTO | Artefacto CORRECTO |
|---|---|---|
| ¿Entienden la navegación? | Sketch (muy bajo) | Wireframe o clickable |
| ¿Les gusta el branding? | Wireframe (sin visual design) | Mockup alta fidelidad |
| ¿Pueden usarlo bajo estrés? | Clickable (mock data) | Coded build con data real |
| ¿Van a pagar? | Mockup estático | Producto live con Stripe real |
Señal de fidelity mismatch: los usuarios constantemente dan feedback sobre cosas que no podés medir con el artefacto actual ("el color de este botón no me gusta" en un wireframe gris). Re-evaluar si el artefacto es correcto para la pregunta.
Cuando el usuario invoca esta skill, guía el diálogo con:
FG-1: "¿Qué artefacto tenés listo para el próximo test?
FG-2: "¿Cuál es tu pregunta de investigación principal? (una oración)"
FG-3: Evaluar fidelity vs. pregunta. Si hay mismatch, sugerir:
FG-4 (opcional): "¿Querés que documente esta decisión en
docs/ux-research/fidelity-decisions/?"
design-studio: después del ejercicio, decidir qué nivel de fidelidad usar para
prototipar la solución convergidaresearch-cadence: cada semana (lunes) consultar fidelity-guide si hay dudas
sobre qué testear el juevesmap-workshop: después de crear mapas, decidir a qué nivel prototipar los
touchpoints identificadosbusiness-model-toolkit:customer-interview-system: el tipo de MVP seleccionado
(Fase 8 de BMT) tiene un nivel de fidelidad asociado:
npx claudepluginhub dojocodinglabs/ux-research-toolkit --plugin ux-research-toolkitSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.