Hace unos días lancé una pregunta básica en un directo de Twitch: ¿Por dónde empezarías un proyecto? Me sorprendió la variedad de respuestas, así que decidí llevar la discusión a mis redes sociales para analizarla más a fondo.
Me llevé una amarga sorpresa: prácticamente había unanimidad, y esto no suele ser una buena señal.
Los resultados fueron bastante sorprendentes. De hecho, la mayoría de las respuestas coincidieron en algo que, para mí, fue una alarma.
✋ Ojo: esto no se trata de decirte que estás haciendo las cosas mal, sino de promover y defender la variedad de ideas y enfoques. Abrir la mente a otras formas de empezar un proyecto es una forma de enriquecer nuestro background y crecer profesionalmente.
En nuestro sector, nada está escrito en piedra y no hay verdades absolutas, así que ver que no hay confrontación de ideas no es precisamente buena señal.
Vamos a ver cómo se distribuyen las respuestas:
Análisis de la encuesta
La pregunta era sencilla: ¿por dónde empezarías un proyecto? Las respuestas:
A) Diseño
B) Lógica
C) UX - Experiencia de usuario
Déjame en comentarios tu respuesta, luego sigues leyendo.
Resultados de Instagram
Diseño → 10%
Lógica / funcionalidad → 80%
UX → 10%
Resultados de LinkedIn
Diseño → 8%
Lógica / funcionalidad → 69%
UX → 23%
Resultado final
Los resultados finales mostraron una clara preferencia por la lógica y funcionalidad, como se puede ver en las encuestas. Pero, ¿por qué? ¿Es esto realmente lo más importante al comenzar un proyecto?
Esto despertó una alarma dentro de mí, esperaba una serie de confrontaciones entre lógica vs UX vs UI.
Decidí investigar un poco más sobre mi audiencia. Gracias a las métricas de LinkedIn, descubrí que más del 48 % son personas sin experiencia, y otro 34 % son junior developers.
Lo siento, tenemos que hablar
Durante los estudios nos enfocan —y nos enfocamos— en sacar los ejercicios de tal manera que cumplan con la tarea o el examen. Y dado que estamos estudiando y debe poder ser evaluado, esto certifica que tienes esos conocimientos, muchas veces en tiempo récord.
En el mundo real esto no puede ser así.
Pero en el mundo real esto no es suficiente. Un proyecto no solo debe funcionar, sino también ofrecer una experiencia fluida y accesible para el usuario.
Y te pongo dos ejemplos de aplicaciones que has utilizado.
Comenzamos con un ejemplo: un juego, y no cualquier juego.
Minecraft
Ha sido el juego más jugado y vendido durante una década. Y aunque últimamente ha mejorado increíblemente su rendimiento, durante mucho tiempo —en la versión de Java— fue un gran dolor de cabeza por el alto consumo de recursos, FPS completamente inestables, además de que solo usaba un hilo de procesamiento para todo el trabajo y las mecánicas como la redstone pegaban tirones importantes. Esto se aleja mucho de la idea de "primero que funcione", y aun así, el juego ha sido líder.
¿Y por qué es tan usado si siempre ha funcionado mal y pedía demasiados recursos?
Entre muchas de las cosas que lo han mantenido líder, la que más destaco es su simplicidad y libertad. Puedes hacer lo que quieras, tiene gráficos sencillos que todo el mundo entiende, sin tutorial, incluso durante los inicios sin logros ni misiones. Es tan sencillo, tan fácil, que cualquiera en unos minutos puede empezar. Además, es tan versátil que tienes mil formas de jugar y usarlo. Tanto es así, que se ha utilizado en sectores como ventas y educación.
¿Te imaginas hacer esto mismo con juegos más elaborados como League of Legends? Estos juegos sí necesitan cierta complejidad para analizar. Tienes que aprenderte todas las mecánicas y combinaciones (que no son pocas), y además está en constante evolución.
En resumen, la experiencia de usuario en Minecraft ha sido increíble, y pocos juegos han logrado replicar algo similar.
Aquí puedes decir: "Bueno, esto es un juego, ¿no? No tiene nada que ver con desarrollar apps".
Pues... el concepto es el mismo. Pero aun así, te muestro otro ejemplo:
Instagram, aunque tiene serios problemas de rendimiento, sigue siendo una de las aplicaciones más adictivas. Su éxito no radica en la perfección técnica, sino en la experiencia de usuario que ha logrado crear: es fácil de usar, simple, directa, y su diseño provoca que los usuarios se queden.
¡Vaya!... volvemos a otra app que funciona fatal, pero con una experiencia de usuario impecable, al menos en lo que se refiere a retención.
Podría ponerte ejemplos como Canva vs Photoshop, Figma vs Adobe XD o Windows vs Mac.
¿Cuándo funciona realmente funcionalidad primero?
Cuando la herramienta está totalmente enfocada a procesos internos, herramientas muy, muy técnicas y muy, muy de nicho. Ahí funciona perfecto.
Herramientas como Jira y administración de consolas como AWS, donde tienen una potencia técnica increíble y el usuario final va enfocado a su funcionalidad (aunque la primera debería ponerse las pilas en UX... es un dolor de cabeza, en serio).
Un criterio más realista
Basándome en comentarios que se hicieron, podríamos sacar un path más realista:
Primero, las matemáticas
Tener una lógica impecable y una experiencia de usuario perfecta no sirve de nada si la aplicación no es viable. Antes de comenzar a desarrollar, asegúrate de que el proyecto sea realizable y que haya un enfoque claro en la viabilidad.
Lo sé, esto se aleja muchísimo de estar estudiando, haciendo prácticas o siendo junior, pero ve ampliando ya tu horizonte.
Segundo, identificar el problema
Antes de escribir una sola línea de código, pregúntate:
¿Qué problema estamos resolviendo? ¿Qué solución podemos ofrecer?
Definir esto con claridad es el primer paso.
Ofrecer soluciones al problema
Y aquí sí: aquí entra todo documento técnico con la funcionalidad y, por supuesto, la experiencia de usuario. Y una vez tenemos todo esto claro, ya vamos a empezar con arquitecturas, stacks y diseño.
Antes de escribir una línea de código, pregúntate:
¿Hay una necesidad real? ¿Es viable económicamente? ¿Quién va a usar esto y cómo lo va a sentir?
Importante: no puedes crear una app que no se entienda, que no se sepa usar o que aporte más problemas al usuario final.
Recuerda: aportamos valor y hacemos que todo sea más accesible y cómodo. Por supuesto, como todo en nuestro campo, nada es fijo y todo cambia según el escenario, el proyecto y la finalidad.
Pero desde ya, olvídate de centrar todo en la funcionalidad.
Nuestro trabajo es aportar valor y solventar problemas.
No es solamente escribir código.
En resumen, nuestro trabajo como desarrolladores no es solo escribir código.
Es resolver problemas y aportar valor.
Si centramos todo en la funcionalidad sin tener en cuenta la experiencia del usuario, corremos el riesgo de crear soluciones complicadas que no sean útiles.
Y no, esto no va de decir qué está bien o mal. Se trata de abrir el debate, sumar puntos de vista y nutrir nuestro background para que, poco a poco, sepamos por qué hacemos lo que hacemos… y no solo cómo hacerlo.
¿Qué opinas? ¿Por dónde empezarías tú un proyecto?
¡Déjame tu respuesta en los comentarios!
🙌 Si te gustó este post, sígueme en mis redes.
Top comments (0)