La Arquitectura de Sistemas
Definición
Hace muchos años, cuando lo expertos se congregaron en una conferencia de la NATO, se analizó el fallo de la construcción de un sistema operativo. El sistema se había dividido en varios módulos, y se le dio uno de esos módulos a sendos equipos de ingenieros de software. Cada equipo presento lo mejor de lo mejor, pero al poner los módulos todos juntos, el sistema fue un desastre. ¿Qué había pasado? Uno de los asistentes, de apellido Sharp, dijo algo como “hemos puesto a varios ingenieros, pero ningún arquitecto”. Se refería a que el trabajo se centró en hacer módulos funcionales con los más altos estándares de la ingeniería, pero nadie supervisó la consecución del objetivo global.
Aunque se tienen a pensar en la arquitectura y la ingeniería de software como análogas a la arquitectura e ingeniería de construcción que todos conocemos, son un tanto diferentes.
En primer lugar, la arquitectura en sistemas es una “cosa”:
Pero también, el proceso de trabajar con esa arquitectura se define como:
El árte o ciencia del diseño y entrega de estratégias tecnológicas valuables.
La estructura o estructuras del Sistema
que incluyen elementos de software,
las propiedades externamente visibles de estos
y las relaciones entre ellos.
La arquitectura es muy importante porque se concentra no en la construcción de una solución, sino en que la solución sea la correcta, que de los frutos que se espera, y lo haga con la mejor calidad.
Para entender eso, necesitamos comprender algunos conceptos.
¿Qué es un sistema?
Los sistemas son estructuras de elementos que se interrelacionan entre sí, y presentan ciertos atributos visibles. La importancia de los sistemas no solo radica en los elementos que los componen, sino en las relaciones. Un grupo de elementos puede formar sistemas diferentes con resultados distintos si se relacionan diferente uno del otro. Los atributos o propiedades se dividen en dos: los comportamientos externamente visibles y las propiedades cualitativas. Veamos un ejemplo:
Cuando construyo una calculadora, puedo poner botones con un dos, un más (+) y un igual (=) lo que me permitiría calcular 2+2= y obtener un 4. Eso es un comportamiento externamente visible. Ahora, si la calculadora no tiene una tecla 2, sino teclas de flechas para aumentar o disminuir el valor, la escritura de la operación sería mucho más difícil, pero al final dará el mismo resultado. La facilidad de uso sería en este caso una propiedad cualitativa.
La arquitectura, para poder lograr los objetivos, necesitará asegurar que se cumplan los comportamientos externamente visibles, pero con las mejores propiedades cualitativas.
Stakeholders.
Pero, cuando construimos la calculadora, debemos pensar en quiénes la usarán. ¿Tendrán problemas de vista, de manipulación? ¿La usarán para trabajo en primaria, o para cálculos científicos, o tal vez para financieros? ¿Quiénes la construirán? ¿Quiénes la venderán? A todos esos actores relacionados con la construcción y uso de la calculadora (o su arquitectura) se les conoce como stakeholders. La arquitectura debe estar pensada y construida para solventar sus necesidades y preocupaciones. Si esto no se cumple, la calculadora podrá ser la más grande maravilla de la ingeniería, pero sin lograr su propósito. La labor del arquitecto es identificar a esos stakeholders, obtener sus preocupaciones y diseñar y construir una arquitectura que las supla.
Pero ¿qué tal si dicha solución ya existe?
Arqueología de Software
Todo sistema tiene su arquitectura, aunque nadie la conozca ni esté descrita. La analogía con la arqueología se aplica al proceso de analizar sistemas existentes para poder aprender cómo es su arquitectura y describirla para ajustes. Hay que revisar documentación, procesos, métodos, la filosofía usada (que puede variar dependiendo del tiempo en que se construyó) y todo eso nos lleva a “elicitar” la arquitectura (o descubrirla).
Proceso arquitectural
La arquitectura sigue un proceso cíclico, que inicia como mencionamos por obtener las preocupaciones de los stakeholder y hacer una lista de requerimientos.
Luego, el arquitecto debe “definir” una arquitectura (o los cambios a la actual) que es como diseñarla. Este proceso es muy complejo porque tiene que tomar en cuenta todos los comportamientos externamente visibles para que cumplan con el producto requerido, y selecciona muy bien los atributos de calidad para que el resultado cumpla con los requerimientos.
Una vez lograda la definición, se pasa a construir. Este proceso puede devolverse a la definición si se valida que los objetivos no se cumplen. Una vez construido, se pone a trabajar y con el tiempo se medirá su cumplimiento. Luego de un periodo de trabajo, se realizará una valoración de cumplimiento, que puede incluir nuevos requerimientos por cosas ajenas como cambios en el mercado, o factores como el rendimiento mismo del sistema. El resultado de esa valoración será una nueva lista de requerimiento o ajustes a los mismos que deberán reiniciar el ciclo.
Consideraciones y evolución
¿Qué cosas podría cambiar en la revaloración? Mucho, porque el cambio es constante y hay que seguirle el paso. Justamente, el proceso es cíclico porque requiere constante revaloración.
Veamos este cuadro de consideraciones.
¿Qué pasa si crecemos, si crecen la cantidad de clientes o quienes usan el sistema? En ese caso se requería revisar la concurrencia de este (cuantos usuarios a la vez), la escalabilidad (cómo responde a incrementos de uso) y el rendimiento (la afectación en el tiempo para completar tareas). Cada una de esas es una propiedad cualitativa.
Si pensamos en un negocio donde me interese la aceptación de los clientes, propiedades como la innovación (novedad), a quienes alcanzará, y la facilidad del uso (User Experience, UX) son criterios que hay que evaluar.
O, por ejemplo, si tenemos un problema con la competencia. ¿Cómo hacemos para lograr alcanzar al competidor que tiene ventaja sobre nosotros? ¿Cómo logramos ventaja sobre el competidor? Elementos diferenciadores, mejor resolución de problemas, mejor calidad de servicio, o rapidez, o más facilidades, etc. Todos criterios y estrategias para lograr objetivos como mayores ventas, más clientes, más presencia en el mercado, etc.
Contexto
Pero la arquitectura no funciona, como ya vimos, enfocada en el sistema solamente. Muchos de los criterios apuntan a elementos externos que influyen en el resultado y las decisiones que tomamos. En la imagen podemos ver dos casas, diferentes. Cada una representa a un competidor en el mercado. Nótese que uno tiene chimenea, más ventanas, el otro es más alto y con puertas dobles. El suelo en el que se encuentran es su base, las cosas que dan soporte a los negocios. El viento que sopla son los vientos de cambio, que auguran modificaciones futuras al mercado. Las estrellas son oportunidades. Una revaloración debe tomar en cuenta todo ese contexto. Una definición arquitectural que tome en cuenta las indicaciones de los vientos, o que aproveche el suelo, o apueste a las estrellas, tendrá mayores posibilidades de lograr los objetivos estratégicos. Si lo hace, pero no se logra el cometido, siempre hay posibilidad de reevaluar y redefinir la arquitectura en el siguiente ciclo.
Modernización
Modernizar no significa botar lo viejo y usar solo tecnología de punta. La modernización se refiere más bien a actualizar toda nuestra arquitectura a los tiempos actuales (modernos). Así, eso no implica eliminar lo viejo, porque mucho de eso aún puede estar vigente. Por eso, aunque hay posibilidad de hacer cosas automatizadas, aún los procesos manuales pueden ser requeridos por ofrecer mayor control de lo ejecutado. A pesar de ser todo digital, algunas cosas análogas aún son geniales. Y, en términos de negocio, mis clientes pueden ser algunos más tradicionalistas, y otros más sedientos de innovación. Por tanto, la modernización es más un proceso arquitectural de revaloración y redefinición de arquitectura, pero tomando en cuenta todo el contexto de forma pragmática.
Pilares.
El conocimiento requerido para poder trabajar en arquitectura se concentra, según Iasa, en 5 pilares.
Ambiente TI: Se refiere a todo lo concerniente a las Tecnologías de Información, incluyendo lenguajes, plataformas, hardware, etc. Eso es muy importante porque la arquitectura busca generar estrategias tecnológicas y es menester entonces conocer de tecnología.
Business Technology Strategy: El BTS se adentra en toda la teoría de estrategia de negocios y es un pilar que llena la parte del conocimiento del negocio y la industria, necesaria para entender la misión y los factores de éxito necesarios.
Diseño: Este pilar es muy importante porque es la manera en la que se definen y describen las soluciones, utilizando técnicas para generar productos de alta calidad, validables y ajustables. El proceso de diseño utilizar los demás pilares para lograr una solución óptima.
Dinámicas Humanas: Este pilar parece no encajar mucho, pero es de lo más fundamental, porque el arquitecto trabaja con sistemas cuyos componentes incluyen personas, organizaciones, entidades. Dentro de estas dinámicas humanas encontramos comunicación, liderazgo, políticas, educación, y muchas herramientas para trabajar con personas que nos permiten obtener y entender las necesidades y cumplirlas.
Atributos de Calidad: Este pilar es primordial porque recoge las propiedades cualitativas que requiere nuestra solución y permite la consecución de las metas. Recordemos que podemos crear un sistema muy bien diseñado que podría no cumplir los objetivos debido a sus propiedades cualitativas. Por ejemplo, un sistema que permita vender tiquetes para conciertos, pero cuando llega un artista famoso, no soporta la avalancha de compras y deja de funcionar. El atributo de calidad correspondiente a la escalabilidad falla, a pesar de que el sistema cumpla con vender los tiquetes correctamente.
Experiencia de Usuario.
Definición
Muchas veces, la Experiencia de Usuario o UX por su pronunciación en inglés, se confunde con UI o Interfaz de Usuario. Y es que cuando hablamos de interfaz de usuario nos referimos a la manera en la que el usuario interactuará con nuestro sistema. Sin embargo, hay una gran diferencia: el UX va más allá de un diseño de interacción.
Aunque es parte de la interacción, el UX tiene tres partes principales: los objetivos que se buscan cumplir, un estado que se pretende logre el usuario con nuestro sistema, y las herramientas para lograrlo. Pongamos un ejemplo.
Tenemos un restaurante y queremos que nuestros clientes nos visiten seguido y nos recomienden. Esos son los objetivos. Un cliente puede llegar y no gustarle algo de nuestro restaurante, y puede que no vuelva o peor, puede que le diga a la gente que no venga. Entonces, crear una aplicación fantástica con lo mejor de diseño gráfico, con colores que calmen e inciten el apetito, facilidad de uso, etc, puede que nos ayude para que el cliente quiera volver, pero eso no sería todo. La atención, la calidad de la comida, la resolución de conflicto (cosa que mencionaremos luego) dan una experiencia completa al usuario que jugará a favor o en contra de nuestro negocio.
Quiero hacer notar que el trabajo en UX se parece un poco al trabajo arquitectural, porque hay primero que determinar los “stakeholders”, captar sus necesidades y diseñar una experiencia que logre los objetivos que se planteen.
Proceso
El trabajo en UX se divide en fases según sea quien enseñe la teoría, pero en general podemos identificar los siguientes:
Identificación de Objetivos: Para poder trabajar en un diseño de experiencia de usuario, es necesario primero saber qué queremos lograr con nuestro producto o servicio. Por ejemplo, un restaurante querrá que sus clientes queden satisfechos y que tengan placer de la comida, mientras que una película de terror querrá que queden aterrados. Es importante aclarar que los objetivos no necesariamente se centran en cómo pasará o quedará sintiendo el cliente, sino lo que queremos lograr (más ventas, más visitas, más viralidad, etc). El sentimiento que se provoca puede no ser un fin sino un medio.
Identificación de Personas: “Persona” es un concepto similar a perfil. Es decir, describe el conjunto de características que identifican a un perfil del cuál tenemos interés. Por ejemplo, si nuestro restaurante es de comida sobria, fina, queremos atraer a clientes que sepan degustar un buen plato, y no tanto a los que aman a la comida rápida por sobre todas las cosas. La definición de una Persona no solo ayuda para identificar a cuáles queremos, sino también cuáles serían las cosas que debemos cuidar o explotar para brindarles una experiencia que logre nuestros objetivos.
Análisis: Este paso es importante porque con él recopilamos información necesaria para crear un buen diseño de UX. Implica documentar cosas como los procesos que llevamos a cabo, los diferentes roles que juegan los elementos del sistema, la participación, las características y reacciones de las diferentes personas, etc.
Diseño de Estrategia: Con la información anterior podemos comenzar con un diseño de estrategia de UX que busque lograr los objetivos al aplicarla a las diferentes personas.
Prueba: Es paso es infaltable. Una vez definida la estrategia, hay que probarla para determinar qué tan exitosa es, y si requiere de mejoras y ajustes. Nótese que esto puede implicar probar incluso en situaciones reales y hacer nuevas rondas de estos pasos cada cierto tiempo para refrescar y mejorar la experiencia de usuario.
Hay una serie de consejos prácticos y técnicas para cada una de las tareas en los pasos anteriores, que el lector podrá revisar en las referencias al final del documento.
Referencias
Iasa Global [https://iasaglobal.org/]
El Contexto del Sistema [https://ieeexplore.ieee.org/document/5290673]
Arquitectura y Stakeholders [https://www.viewpoints-and-perspectives.info/]
Visualización de Arquitectura [https://c4model.com/] [https://medium.com/@nvashanin/documentation-in-software-architecture-4f2e4159c4fc]
Estilos Arquitecturales [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013]
Arqueología de Software [https://dl.gi.de/handle/20.500.12116/21649]
Stakeholders [https://www.researchgate.net/figure/The-key-stakeholder-roles-in-architecture-design-and-description_tbl4_220920579]
[https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9]
[https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap24.html]
Introducción a UX [https://www.interaction-design.org/literature/topics/ux-design]
[https://www.amazon.com/gp/product/0521137934]
Iasa 5 Pilares [https://www.infoq.com/news/2012/07/iasa-wilt-five-pillars/]
Modernización basada en Arquitectura [https://wiprodigital.com/2020/04/10/an-architecture-driven-approach-to-application-modernization/]
[https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/modernizing-it-for-a-digital-era#]
Resumen de UX for Dummies [https://www.dummies.com/web-design-development/site-development/ux-for-dummies-cheat-sheet/]
UX Planet [https://uxplanet.org/].
Personas [https://uxplanet.org/how-to-create-personas-step-by-step-guide-303d7b0d81b4]
[https://www.justinmind.com/blog/user-persona/]
Pasos [https://www.invisionapp.com/inside-design/6-stages-ux-process/]
La Arquitectura de Sistemas
Definición
Hace muchos años, cuando lo expertos se congregaron en una conferencia de la NATO, se analizó el fallo de la construcción de un sistema operativo. El sistema se había dividido en varios módulos, y se le dio uno de esos módulos a sendos equipos de ingenieros de software. Cada equipo presento lo mejor de lo mejor, pero al poner los módulos todos juntos, el sistema fue un desastre. ¿Qué había pasado? Uno de los asistentes, de apellido Sharp, dijo algo como “hemos puesto a varios ingenieros, pero ningún arquitecto”. Se refería a que el trabajo se centró en hacer módulos funcionales con los más altos estándares de la ingeniería, pero nadie supervisó la consecución del objetivo global.
Aunque se tienen a pensar en la arquitectura y la ingeniería de software como análogas a la arquitectura e ingeniería de construcción que todos conocemos, son un tanto diferentes.
En primer lugar, la arquitectura en sistemas es una “cosa”:
Pero también, el proceso de trabajar con esa arquitectura se define como:
El árte o ciencia del diseño y entrega de estratégias tecnológicas valuables.
La estructura o estructuras del Sistema
que incluyen elementos de software,
las propiedades externamente visibles de estos
y las relaciones entre ellos.
La arquitectura es muy importante porque se concentra no en la construcción de una solución, sino en que la solución sea la correcta, que de los frutos que se espera, y lo haga con la mejor calidad.
Para entender eso, necesitamos comprender algunos conceptos.
¿Qué es un sistema?
Los sistemas son estructuras de elementos que se interrelacionan entre sí, y presentan ciertos atributos visibles. La importancia de los sistemas no solo radica en los elementos que los componen, sino en las relaciones. Un grupo de elementos puede formar sistemas diferentes con resultados distintos si se relacionan diferente uno del otro. Los atributos o propiedades se dividen en dos: los comportamientos externamente visibles y las propiedades cualitativas. Veamos un ejemplo:
Cuando construyo una calculadora, puedo poner botones con un dos, un más (+) y un igual (=) lo que me permitiría calcular 2+2= y obtener un 4. Eso es un comportamiento externamente visible. Ahora, si la calculadora no tiene una tecla 2, sino teclas de flechas para aumentar o disminuir el valor, la escritura de la operación sería mucho más difícil, pero al final dará el mismo resultado. La facilidad de uso sería en este caso una propiedad cualitativa.
La arquitectura, para poder lograr los objetivos, necesitará asegurar que se cumplan los comportamientos externamente visibles, pero con las mejores propiedades cualitativas.
Stakeholders.
Pero, cuando construimos la calculadora, debemos pensar en quiénes la usarán. ¿Tendrán problemas de vista, de manipulación? ¿La usarán para trabajo en primaria, o para cálculos científicos, o tal vez para financieros? ¿Quiénes la construirán? ¿Quiénes la venderán? A todos esos actores relacionados con la construcción y uso de la calculadora (o su arquitectura) se les conoce como stakeholders. La arquitectura debe estar pensada y construida para solventar sus necesidades y preocupaciones. Si esto no se cumple, la calculadora podrá ser la más grande maravilla de la ingeniería, pero sin lograr su propósito. La labor del arquitecto es identificar a esos stakeholders, obtener sus preocupaciones y diseñar y construir una arquitectura que las supla.
Pero ¿qué tal si dicha solución ya existe?
Arqueología de Software
Todo sistema tiene su arquitectura, aunque nadie la conozca ni esté descrita. La analogía con la arqueología se aplica al proceso de analizar sistemas existentes para poder aprender cómo es su arquitectura y describirla para ajustes. Hay que revisar documentación, procesos, métodos, la filosofía usada (que puede variar dependiendo del tiempo en que se construyó) y todo eso nos lleva a “elicitar” la arquitectura (o descubrirla).
Proceso arquitectural
La arquitectura sigue un proceso cíclico, que inicia como mencionamos por obtener las preocupaciones de los stakeholder y hacer una lista de requerimientos.
Luego, el arquitecto debe “definir” una arquitectura (o los cambios a la actual) que es como diseñarla. Este proceso es muy complejo porque tiene que tomar en cuenta todos los comportamientos externamente visibles para que cumplan con el producto requerido, y selecciona muy bien los atributos de calidad para que el resultado cumpla con los requerimientos.
Una vez lograda la definición, se pasa a construir. Este proceso puede devolverse a la definición si se valida que los objetivos no se cumplen. Una vez construido, se pone a trabajar y con el tiempo se medirá su cumplimiento. Luego de un periodo de trabajo, se realizará una valoración de cumplimiento, que puede incluir nuevos requerimientos por cosas ajenas como cambios en el mercado, o factores como el rendimiento mismo del sistema. El resultado de esa valoración será una nueva lista de requerimiento o ajustes a los mismos que deberán reiniciar el ciclo.
Consideraciones y evolución
¿Qué cosas podría cambiar en la revaloración? Mucho, porque el cambio es constante y hay que seguirle el paso. Justamente, el proceso es cíclico porque requiere constante revaloración.
Veamos este cuadro de consideraciones.
¿Qué pasa si crecemos, si crecen la cantidad de clientes o quienes usan el sistema? En ese caso se requería revisar la concurrencia de este (cuantos usuarios a la vez), la escalabilidad (cómo responde a incrementos de uso) y el rendimiento (la afectación en el tiempo para completar tareas). Cada una de esas es una propiedad cualitativa.
Si pensamos en un negocio donde me interese la aceptación de los clientes, propiedades como la innovación (novedad), a quienes alcanzará, y la facilidad del uso (User Experience, UX) son criterios que hay que evaluar.
O, por ejemplo, si tenemos un problema con la competencia. ¿Cómo hacemos para lograr alcanzar al competidor que tiene ventaja sobre nosotros? ¿Cómo logramos ventaja sobre el competidor? Elementos diferenciadores, mejor resolución de problemas, mejor calidad de servicio, o rapidez, o más facilidades, etc. Todos criterios y estrategias para lograr objetivos como mayores ventas, más clientes, más presencia en el mercado, etc.
Contexto
Pero la arquitectura no funciona, como ya vimos, enfocada en el sistema solamente. Muchos de los criterios apuntan a elementos externos que influyen en el resultado y las decisiones que tomamos. En la imagen podemos ver dos casas, diferentes. Cada una representa a un competidor en el mercado. Nótese que uno tiene chimenea, más ventanas, el otro es más alto y con puertas dobles. El suelo en el que se encuentran es su base, las cosas que dan soporte a los negocios. El viento que sopla son los vientos de cambio, que auguran modificaciones futuras al mercado. Las estrellas son oportunidades. Una revaloración debe tomar en cuenta todo ese contexto. Una definición arquitectural que tome en cuenta las indicaciones de los vientos, o que aproveche el suelo, o apueste a las estrellas, tendrá mayores posibilidades de lograr los objetivos estratégicos. Si lo hace, pero no se logra el cometido, siempre hay posibilidad de reevaluar y redefinir la arquitectura en el siguiente ciclo.
Modernización
Modernizar no significa botar lo viejo y usar solo tecnología de punta. La modernización se refiere más bien a actualizar toda nuestra arquitectura a los tiempos actuales (modernos). Así, eso no implica eliminar lo viejo, porque mucho de eso aún puede estar vigente. Por eso, aunque hay posibilidad de hacer cosas automatizadas, aún los procesos manuales pueden ser requeridos por ofrecer mayor control de lo ejecutado. A pesar de ser todo digital, algunas cosas análogas aún son geniales. Y, en términos de negocio, mis clientes pueden ser algunos más tradicionalistas, y otros más sedientos de innovación. Por tanto, la modernización es más un proceso arquitectural de revaloración y redefinición de arquitectura, pero tomando en cuenta todo el contexto de forma pragmática.
Pilares.
El conocimiento requerido para poder trabajar en arquitectura se concentra, según Iasa, en 5 pilares.
Ambiente TI: Se refiere a todo lo concerniente a las Tecnologías de Información, incluyendo lenguajes, plataformas, hardware, etc. Eso es muy importante porque la arquitectura busca generar estrategias tecnológicas y es menester entonces conocer de tecnología.
Business Technology Strategy: El BTS se adentra en toda la teoría de estrategia de negocios y es un pilar que llena la parte del conocimiento del negocio y la industria, necesaria para entender la misión y los factores de éxito necesarios.
Diseño: Este pilar es muy importante porque es la manera en la que se definen y describen las soluciones, utilizando técnicas para generar productos de alta calidad, validables y ajustables. El proceso de diseño utilizar los demás pilares para lograr una solución óptima.
Dinámicas Humanas: Este pilar parece no encajar mucho, pero es de lo más fundamental, porque el arquitecto trabaja con sistemas cuyos componentes incluyen personas, organizaciones, entidades. Dentro de estas dinámicas humanas encontramos comunicación, liderazgo, políticas, educación, y muchas herramientas para trabajar con personas que nos permiten obtener y entender las necesidades y cumplirlas.
Atributos de Calidad: Este pilar es primordial porque recoge las propiedades cualitativas que requiere nuestra solución y permite la consecución de las metas. Recordemos que podemos crear un sistema muy bien diseñado que podría no cumplir los objetivos debido a sus propiedades cualitativas. Por ejemplo, un sistema que permita vender tiquetes para conciertos, pero cuando llega un artista famoso, no soporta la avalancha de compras y deja de funcionar. El atributo de calidad correspondiente a la escalabilidad falla, a pesar de que el sistema cumpla con vender los tiquetes correctamente.
Experiencia de Usuario.
Definición
Muchas veces, la Experiencia de Usuario o UX por su pronunciación en inglés, se confunde con UI o Interfaz de Usuario. Y es que cuando hablamos de interfaz de usuario nos referimos a la manera en la que el usuario interactuará con nuestro sistema. Sin embargo, hay una gran diferencia: el UX va más allá de un diseño de interacción.
Aunque es parte de la interacción, el UX tiene tres partes principales: los objetivos que se buscan cumplir, un estado que se pretende logre el usuario con nuestro sistema, y las herramientas para lograrlo. Pongamos un ejemplo.
Tenemos un restaurante y queremos que nuestros clientes nos visiten seguido y nos recomienden. Esos son los objetivos. Un cliente puede llegar y no gustarle algo de nuestro restaurante, y puede que no vuelva o peor, puede que le diga a la gente que no venga. Entonces, crear una aplicación fantástica con lo mejor de diseño gráfico, con colores que calmen e inciten el apetito, facilidad de uso, etc, puede que nos ayude para que el cliente quiera volver, pero eso no sería todo. La atención, la calidad de la comida, la resolución de conflicto (cosa que mencionaremos luego) dan una experiencia completa al usuario que jugará a favor o en contra de nuestro negocio.
Quiero hacer notar que el trabajo en UX se parece un poco al trabajo arquitectural, porque hay primero que determinar los “stakeholders”, captar sus necesidades y diseñar una experiencia que logre los objetivos que se planteen.
Proceso
El trabajo en UX se divide en fases según sea quien enseñe la teoría, pero en general podemos identificar los siguientes:
Identificación de Objetivos: Para poder trabajar en un diseño de experiencia de usuario, es necesario primero saber qué queremos lograr con nuestro producto o servicio. Por ejemplo, un restaurante querrá que sus clientes queden satisfechos y que tengan placer de la comida, mientras que una película de terror querrá que queden aterrados. Es importante aclarar que los objetivos no necesariamente se centran en cómo pasará o quedará sintiendo el cliente, sino lo que queremos lograr (más ventas, más visitas, más viralidad, etc). El sentimiento que se provoca puede no ser un fin sino un medio.
Identificación de Personas: “Persona” es un concepto similar a perfil. Es decir, describe el conjunto de características que identifican a un perfil del cuál tenemos interés. Por ejemplo, si nuestro restaurante es de comida sobria, fina, queremos atraer a clientes que sepan degustar un buen plato, y no tanto a los que aman a la comida rápida por sobre todas las cosas. La definición de una Persona no solo ayuda para identificar a cuáles queremos, sino también cuáles serían las cosas que debemos cuidar o explotar para brindarles una experiencia que logre nuestros objetivos.
Análisis: Este paso es importante porque con él recopilamos información necesaria para crear un buen diseño de UX. Implica documentar cosas como los procesos que llevamos a cabo, los diferentes roles que juegan los elementos del sistema, la participación, las características y reacciones de las diferentes personas, etc.
Diseño de Estrategia: Con la información anterior podemos comenzar con un diseño de estrategia de UX que busque lograr los objetivos al aplicarla a las diferentes personas.
Prueba: Es paso es infaltable. Una vez definida la estrategia, hay que probarla para determinar qué tan exitosa es, y si requiere de mejoras y ajustes. Nótese que esto puede implicar probar incluso en situaciones reales y hacer nuevas rondas de estos pasos cada cierto tiempo para refrescar y mejorar la experiencia de usuario.
Hay una serie de consejos prácticos y técnicas para cada una de las tareas en los pasos anteriores, que el lector podrá revisar en las referencias al final del documento.
Referencias
Iasa Global [https://iasaglobal.org/]
El Contexto del Sistema [https://ieeexplore.ieee.org/document/5290673]
Arquitectura y Stakeholders [https://www.viewpoints-and-perspectives.info/]
Visualización de Arquitectura [https://c4model.com/] [https://medium.com/@nvashanin/documentation-in-software-architecture-4f2e4159c4fc]
Estilos Arquitecturales [https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013]
Arqueología de Software [https://dl.gi.de/handle/20.500.12116/21649]
Stakeholders [https://www.researchgate.net/figure/The-key-stakeholder-roles-in-architecture-design-and-description_tbl4_220920579]
[https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9]
[https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap24.html]
Introducción a UX [https://www.interaction-design.org/literature/topics/ux-design]
[https://www.amazon.com/gp/product/0521137934]
Iasa 5 Pilares [https://www.infoq.com/news/2012/07/iasa-wilt-five-pillars/]
Modernización basada en Arquitectura [https://wiprodigital.com/2020/04/10/an-architecture-driven-approach-to-application-modernization/]
[https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/modernizing-it-for-a-digital-era#]
Resumen de UX for Dummies [https://www.dummies.com/web-design-development/site-development/ux-for-dummies-cheat-sheet/]
UX Planet [https://uxplanet.org/].
Personas [https://uxplanet.org/how-to-create-personas-step-by-step-guide-303d7b0d81b4]
[https://www.justinmind.com/blog/user-persona/]
Pasos [https://www.invisionapp.com/inside-design/6-stages-ux-process/]
