loading...
Cover image for Del diseño de UI al desarrollo frontend: un viaje inesperado

Del diseño de UI al desarrollo frontend: un viaje inesperado

iamdoomling profile image Bel Rey ・3 min read

Siendo este el primer post creo que es necesaria una breve introducción que brinde contexto a mi historia: Hola, mi nombre es Belén Rey y soy diseñadora de interfaces.

Hace aproximadamente seis años fundé junto a dos socios, una pequeña software factory. Por aquel entonces yo me desempeñaba en puestos de quality assurance y estaba empezando a tomar mis primeros trabajos freelance en diseño.

Mi rol en la empresa siempre estuvo claro, ellos programaban, yo hacía diseños o QA según las necesidades particulares de cada cliente. A veces ambas. A veces ninguna. A ellos el trabajo nunca les faltaba.

El código no era para mi algo ajeno. Allá por el 2007 cursé dos años de un terciario en programación de videojuegos. Aprendí C++ y C#, tuve pequeñas experiencias con engines 2d y 3d. Todo ese mundo me resultaba, y aún en día me resulta, sumamente interesante, pero mis propias dudas y el entorno hostil (era la única mujer anotada en la totalidad de la carrera) me hicieron alejarme.

Convencida de que programar no ‘era lo mío’ decidí seguir otra de mis pasiones en la vida: comunicar desde lo gráfico. Siempre tuve facilidad para lo visual, y formarme rodeada de otras personas apasionadas por ese mundo me hizo olvidar temporalmente de los unos y ceros.

Durante la cursada, un poco incentivada por mis demás intereses y otro poco por la dura realidad laboral en la que veía a mis colegas decidí que iba a intentar centrar mi carrera en el diseño de interfaces, preferentemente en el rubro de sistemas. Encontrarme como co-fundadora de una empresa de software me permitió ejercer mi profesión en mis propios términos.


Cuando uno construye una pieza o sistema gráfico siempre está en control de la producción. Obviamente los grandes trabajos se desarrollan en equipo y partes del proceso, por ejemplo la impresión, se tercerizan — Pero el diseñador es siempre responsable y debe controlar constantemente el medio en el que la pieza va a ser reproducida.

Entender de resoluciones y tamaños no es todo, el equipo de diseño suele conocer también aunque no sea en total profundidad los procesos de imprenta, los tipos de tinta que se usan, y los papeles en los que se reproduce el contenido. Todas estas variables son tenidas en cuenta al momento de la construcción gráfica y son una parte inherente al proceso de comunicar.

Cómo podía yo entonces, diseñadora gráfica especializada en UI, sentirme cómoda construyendo para un medio que me resultaba completamente ajeno. Algunas de mis decisiones eran complicadas de implementar, otras eran cambiadas para satisfacer funcionalidades propias de un sitio. Mi diseño pasaba por un estado intermedio de transformación y salía convertido en otra cosa, funcional sí, pero que no transmitía exactamente su intencionalidad original.

Al principio pensé en solucionarlo hablando con mi equipo. Siempre tuvieron mucha paciencia y se tomaban todo el trabajo de explicarme — pero a mi no me alcanzaba. Necesitaba recuperar el control sobre mi proceso de diseño para construir piezas funcionales y a la vez memorables. Piezas que transmitan algo más allá que un simple template.

En un momento de iluminación me entendí que necesitaba aprender a programar. Cuando pude quitarme de la cabeza esa idea mística de que lo visual y lo lógico son opuestos la programación se convirtió en otra herramienta más a mi disposición en el proceso de comunicar.

Conocer las limitaciones y los alcances de los lenguajes, con sus librerías y frameworks me ayudó a encarar mi trabajo de otra manera. Mis procesos se volvieron más ágiles. Pensar en componentes me obligó a imaginar estructuras reutilizables y esto afectó de una manera muy profunda mi proceso proyectual.

No estoy diciendo con esto que todos los diseñadores de UI deban aprender a programar, pero si los insto a conocer su medio. Sean curiosos, investiguen. Pregunten por qué esto sí y aquello no pero no desde el desafío, sino desde la ingenuidad de quien quiere romper los límites.


Extendamos la noción de donde termina nuestro trabajo y empieza el de ellos y aprendamos a entender los proyectos como una unión que depende tanto lo que se ve como lo que no. El todo siendo más que la suma de sus partes. Siéntense con sus compañeros programadores, traten de entender su punto de vista y visión del proyecto y no dejen de compartir la suya. No les prometo que vaya a ser fácil, pero vale la pena intentarlo.

Discussion

pic
Editor guide