davila.uno
Choose how you want to explore today
You can switch it anytime.
How much technical knowledge does a UX designer really need? An exploration of the boundary between design and development.
For years I've seen the same pattern repeat itself.
Designers who produce flawless interfaces, but deliver them to development incomplete. Developers who respond with "that can't be done." Rework. Frustration. Decisions that nobody ends up defending.
The question is simple: what should a designer understand about technology to collaborate better, without becoming a developer?
I'm not trying to train programmers. I'm trying to understand where design ends and where a better conversation begins.
Most problems that appear between UX and development are not people conflicts. They are context problems.
Maybe a designer doesn't need to write an API. But perhaps they should understand what an API is. Maybe they don't need to manage a database. But they should understand that data doesn't appear out of nowhere. Perhaps technical literacy is a form of empathy.
After years working with complex systems, I'm starting to suspect that many frictions between UX and development don't come from differences of opinion, but from differences of context. Maybe the problem was never "developers don't understand UX." Perhaps designers don't fully understand how the things we draw are actually built.
The word "framework" makes me a little uncomfortable. It sounds too finished. For now I prefer to think of it as an experiment — a kind of map to answer a bigger question: how to stop being a tourist inside the product-building process?
Topics ahead: mental models for designers, APIs for people who design, states and flows, what a UX designer should know about databases, architecture explained without trauma, design systems and reuse, how to argue with development without it becoming a religious debate, and the phrase "that can't be done" and its many translations.
- Anticipar restricciones. - Deducir retrabajo. - Defender mejor sus decisiones. - Participar en conversaciones más interesantes. - Construir soluciones más realistas- - Aumentar su influencia dentro del equipo.
Initially I intended to create a guide, even a course. I discovered that I first need a manifesto.
Technical concepts generate greater learning when they are presented as real work conversations and not as theoretical classes.
A conversational editorial voice is adopted. Each chapter will begin with a real-life situation and a question before introducing technical concepts.
I'm wrapping up this first day, feeling tired, with the following: ✅ Confirmed: The project will have a Manifesto as its foundation. Learning will be organized using a Maturity Model. The editorial voice will be conversational and question-based. 🧪 Hypothesis: The UX Decision Protocols could become the project's most distinctive artifact. ❓ Pending: Define the official name of the methodology. Design the first Decision Protocol. Establish criteria for evaluating progress between maturity levels
Hoy apareció una idea interesante: los Protocolos de Decisión UX. Todavía no sé si terminarán siendo una pieza central o una ocurrencia que desaparecerá dentro de dos semanas. Por ahora siento que podrían convertirse en uno de los elementos más distintivos del proyecto, pero todavía es demasiado pronto para afirmarlo. También quedó pendiente definir el nombre oficial de la metodología y cómo medir el avance entre niveles de madurez.