Cómo un enfoque OOUX puede ayudar a mantener IA pequeña y simple a medida que escala su aplicación.
Hace unos diez años formé parte del equipo de diseño digital de una de las cadenas de supermercados holandesas más grandes. Al desarrollar nuevas funciones e historias de usuarios, el propietario del producto hizo la misma pregunta: “¿Necesitamos este botón?”
En uno de esos casos, consideramos una importante actualización del sitio web. La aplicación web sirvió principalmente como una lista de compras de planificación de comestibles. Se suponía que el próximo conjunto de características lo llevaría al siguiente nivel y entregaría comestibles.
Hoy parece normal, pero en su momento era algo nuevo. No había mejores prácticas a las que recurrir, así que seguí los estándares de comercio electrónico. Extendí la arquitectura de la información para hacer espacio para el carrito de compras y el proceso de pago. Como se mencionó anteriormente, la primera reacción de mi propietario de producto fue: “¿Necesitamos este botón?” O en este caso particular, ¿necesitamos extender IA y agregar nuevos componentes y subprocesos?
Mi enfoque de crecimiento orgánico haría que la aplicación fuera inmanejable. No solo para el equipo de diseño y desarrollo, sino aún más importante para nuestros usuarios.
Supuse que las funciones importantes necesitaban una nueva interfaz de usuario. Y por lo tanto, tendré que expandir la arquitectura de la información. Fue uno de los primeros proyectos en los que ayudé a hacer crecer el producto. No pensé en las consecuencias. Mi enfoque de crecimiento orgánico haría que la aplicación fuera inmanejable. No solo para el equipo de diseño y desarrollo, sino aún más importante para nuestros usuarios.
¡Y el propietario de mi producto tenía razón! Siguiendo su enfoque, pudimos incorporar nuevas funciones mientras reutilizamos y ampliamos los componentes existentes. Su ojo para las nuevas funciones permitió una interfaz de usuario y una arquitectura de información simplificadas. Al mismo tiempo, ahorró esfuerzos de diseño y desarrollo. Pero, ¿cómo llegó a esta decisión?
En algunos casos, hemos tenido suerte. Podemos empezar desde cero y crear una nueva arquitectura de información. A menudo lo comparo con mudarse a una nueva casa. La única limitación es el plano de planta. Según lo que sabemos, todo se puede arreglar de la manera más ideal.
Sin embargo, al igual que ocurre con nuestros hogares, con el tiempo surgen nuevas necesidades. Algunas cosas eran de esperar y otras no. A veces es suficiente reorganizar varias habitaciones. Pero habrá un punto, como en el ejemplo de mi carrito, donde parece más complicado. Entonces comenzamos a agregar nuevas habitaciones. Nuestra arquitectura de información se está volviendo cada vez más distorsionada y difícil de usar. Idealmente, deberíamos dar un paso atrás y reevaluar la estructura general, pero a menudo nos falta el tiempo o la estructura para hacerlo sobre la marcha.
El propietario de mi producto se dio cuenta de que hay que mirar más allá de los componentes, los flujos e incluso la arquitectura de la información. Observó el sistema, los objetos, que gobiernan nuestra aplicación. Usó algo similar a lo que hoy llamaríamos OOUX.
Esencialmente, OOUX expone una aplicación a través de objetos relacionados. En mi ejemplo anterior, esos objetos serían la lista de compras y los elementos de la lista.
Las nuevas características siempre se sienten como algo diferente, lo que sin duda puede ser el caso. Sin embargo, muy a menudo estas funciones están relacionadas con objetos existentes de una forma u otra.
Primero necesitamos entender el modelo de objeto existente para hacer esta evaluación. El marco ORCA (Objetos, Relaciones, Llamado a la acción, Atributos) proporciona un punto de partida para desglosar una aplicación y crear un mapa base. Esto debería ayudarlo a comprender los objetos, las relaciones y los atributos/elementos de contenido existentes.
- O – Que tipo objetos utilizado en el modelo mental
- R como son estos objetos relatar El uno al otro
- DE – Que tipo llamada a la acción cada objeto
- PERO – Que tipo atributos (o elementos) de los que consta cada objeto
El artículo de Dale Owen “¿Qué es la UX orientada a objetos?” le da una gran visión general del proceso detallado. Una vez que tengamos una línea de base, podemos hacer lo mismo con nuestras nuevas funciones y comenzar a compararlas.
Aquí hay algunos consejos para pensar:
- Considere si hay objetos existentes que tienen significado similar.
- Compruebe si hay objetos que elementos de contenido similar.
- Evaluar si hay otros objetos con misma relacion.
Siempre que los elementos o elementos de relación no se contradigan entre sí, podríamos incluirlos simplemente ampliando su alcance. Esto puede no ser tan fácil como parece y tendremos que jugar con los modelos de objetos para que encajen.
En mi ejemplo anterior, teníamos un objeto de lista de compras que contenía un elemento de lista de compras. Los nuevos objetos son el carro de la compra y el elemento del carro de la compra. Probablemente puedas ver a dónde va esto. La lista de compras y el carrito de compras eran muy similares. La única necesidad adicional era un botón de verificación. Lo mismo ocurría con los objetos. Solo necesitábamos ampliarlos para mostrar el precio y la disponibilidad. Al hacer algunos cambios en los componentes existentes, podríamos habilitar un nivel completamente nuevo de funcionalidad. Como resultado, la arquitectura de la información podría permanecer igual, mientras que el diseño y el desarrollo podrían reducirse.
La próxima vez que esté en un equipo que escale una aplicación, realice una evaluación inicial del modelo de objeto subyacente. Divida cada característica nueva en los elementos requeridos y compárelos. Trate de encontrar formas de usar los objetos existentes. En muchos casos, esto ayudará a evitar la adición de nuevas salas y mantendrá compacta la arquitectura de la información. El esfuerzo inicial ahorrará tiempo en el diseño y desarrollo detallados.
