ia/recon
Jesse James Garrett
jjg@jjg.net
Traslación al español de Horacio Salazar
horacio@daniloblack.com
Versión original (en
inglés)
- La
disciplina y el rol
- Costumbres
tribales
- Con
ropa de laboratorio
- Luego
ocurre un milagro
- El
arquitecto de mañana
- Secretos y
mensajes
Parte 1 de 6: La disciplina y el
rol
Existe una disciplina conocida como arquitectura de información,
y existe un rol, el del arquitecto de información. Se han
desarrollado más o menos de la mano, y hasta ahora cualquier
discusión sobre la una ha implicado discutir al otro. Pero quizás
eso tenga que cambiar.
Nunca hay un momento apropiado para el declive económico, pero
para la comunidad de arquitectura de información, la inflexión
reciente ha sido particularmente inoportuna. Justo cuando
empezábamos a avanzar en la defensa del valor de nuestra
contribución al proceso de 'diseño Web', las presiones económicas
nos están obligando a auto-evangelizarnos con todavía más vigor,
conforme enfrentamos un mayor escepticismo de clientes presionados
por las circunstancias económicas y fatigados por cinco años de los
discursos de venta de aceite de víbora que fueron las dot com.
En la cúspide de la Nueva Economía, algunos de nosotros incluso
dimos vueltas a la noción de que nuestro trabajo sería reconocido en
la comunidad de negocios como algo tan esencial para el éxito de
cualquier empresa que la responsabilidad por estas cuestiones
inevitablemente residiría en el nivel superior de la organización
(el fabuloso e ilusorio 'CXO': Chief eXperience Officer). Hoy, con
la llegada del declive, tanto la disciplina como el rol se sienten
como amenazados por la extinción.
Nuestra respuesta ha sido cerrar filas y tratar de formular un
discurso de venta y una racionalización de negocios para nuestro
trabajo. Pero no estamos realmente seguros de lo que vendemos.
¿Estamos vendiendo la idea de la arquitectura de información, o la
idea del arquitecto de información? Fuera de esta confusión, nos
hemos visto envueltos en un interminable estira y afloja respecto a
cómo definimos la disciplina y el rol.
Una escuela de pensamiento trata de definir la disciplina sobre
la base del rol. El pensamiento parece ser: "Soy un arquitecto de
información; por lo tanto, lo que hago es arquitectura de
información."
Las definiciones basadas en el rol tienden a derivar naturalmente
hacia la amplitud. Como las responsabilidades que corresponden al
rol varían tanto de una organización a otra, la definición del rol
(y por tanto de la disciplina) se hace cada vez más grande. Esta
formulación conduce a la llamada 'gran AI' -- una definición que
comprende un amplio rango de responsabilidades que incluyen
estrategia de negocios, diseño de la información, investigación de
usuarios, diseño de la interacción, recopilación de
requerimientos... la lista parece interminable.
El acercamiento contrario consiste en definir el rol sobre la
base de la disciplina. Sea cual sea el campo de la arquitectura de
información, un arquitecto de información es la persona que se
especializa en este campo.
Estas definiciones tienden a derivar naturalmente hacia la
estrechez. A fin de hablar con sentido sobre los problemas de la
arquitectura de información y sus soluciones, debemos definir el
alcance de estos problemas de maneras muy concretas.
El resultado de esto es la 'pequeña AI' -- estrechamente enfocada
en la organización y estructuración de espacios informativos. Pero
cuando esta definición (configurada para la disciplina) se aplica al
rol, crea en algunos el temor de quedar 'encajonados', atrapados en
un rol tan estrechamente definido que muchos de los elementos
esenciales para el éxito de cualquier arquitectura dada queden fuera
del control de la influencia del arquitecto.
La expansión del rol del arquitecto de información bien podría
trabajar en beneficio del individuo que cumple dicho rol (aunque
quizás menos desde el inicio del declive), pero casi con certeza
está trabajando en detrimento de la disciplina como un todo. Citando
la naturaleza holística del trabajo de la arquitectura de
información, algunas personas claramente no quedarán satisfechas
hasta que tengan control directo sobre todo aspecto del negocio que
pueda afectar a la arquitectura. Este modo de pensar adolece del
peor tipo de arrogancia, y mina cualquier esfuerzo por convencer a
los negocios del valor de la disciplina. Entre más poder quiera uno
demandar, más difícil es convencer a otros de que te permitan
tenerlo.
Se ha vuelto difícil para muchos en la comunidad implicarse en
esta discusión de manera desapasionada. Cualquier propuesta sobre
definir el rol inevitablemente amenaza el sentido de identidad de
alguien --si el rol termina siendo definido de un modo que difiere
de mi descripción de plaza, ¿significa esto que ya no soy un AI? O
peor: ¿significa que soy un farsante?
El resultado es que caminamos en círculos, y la definición de la
disciplina que tiene una persona choca con la definición que tiene
otra persona del rol, y a la inversa. No estamos llegando a ninguna
parte con ninguna de las definiciones.
Cualquier definición lo bastante amplia como para abarcar al rol
es demasiado ancha como para alentar una discusión útil de la
disciplina; cualquier definición lo bastante estrecha para la
disciplina es demasiado angosta para el rol. Parecemos estar en un
punto muerto. Basar cualquier definición en la otra significa que
una será insuficiente. Tratar de formular ambas a la vez no está
funcionando, produciendo el clásico problema del huevo y la
gallina.
La única solución consiste en desacoplar por completo la
definición de la disciplina de la definición del rol. Por poco
intuitivo que esto parezca, es perfectamente razonable, y no carece
de precedentes en otros campos. Por ejemplo, el conductor de una
orquesta tiene una amplia gama de responsabilidades creativas y
administrativas; 'conducir', si bien es ciertamente parte de su
trabajo, no se acerca siquiera a empezar a captar la gama completa
de sus deberes.
Enfrentamos un imponente muro de retos creativos reales, pero en
vez de enfrentarlos nos perseguimos la cola por meses, tratando de
definir términos básicos. Definir la disciplina en términos cada vez
más amplios no hace progresar nuestra comprensión de esos retos.
Elegir una definición limitada para la disciplina nos permite
describir un conjunto particular de problemas con precisión. Y tal
precisión en la expresión es un requisito absoluto para que
cualquier disciplina progrese.
Por su parte, el rol se cuidará solo. Las organizaciones seguirán
haciendo lo que siempre han hecho, definiendo roles conforme los
necesiten y asignando recursos ahí donde produzcan resultados.
Hay otra razón más práctica para divorciar la discusión sobre la
disciplina de la discusión sobre el rol. Bien pudiera ser que, a fin
de conservar la idea de la disciplina de la arquitectura de
información, debamos abandonar la idea del rol del arquitecto de
información.
Parte 2 de 6: Costumbres
tribales
La arquitectura de información abarca un amplio rango de
problemas. Pero sin importar el contexto o los objetivos específicos
de un proyecto de arquitectura de información dado, nuestra
preocupación siempre tiene qué ver con la creación de estructuras
para facilitar una comunicación efectiva. Esta noción es el núcleo
de nuestra disciplina.
Mis antecedentes residen en lo que nuestra industria llama
"desarrollo de contenido", un área conocida para el resto del mundo
como "escribir y editar". Por alguna razón, no muchos de nosotros
hemos hecho la transición de ese mundo al mundo de la AI, y a menudo
descubro que tengo que explicar la conexión.
A lo largo de la historia humana, la gente más preocupada con la
comunicación efectiva ha sido la gente que trabaja con el idioma.
Antes del hipertexto, antes del texto llano mismo, el lenguaje es la
herramienta original para ""arquitecturar" la información.
Cuando la mayoría de las personas piensa en el trabajo de un
editor, creo que se imaginan a alguien enconchado sobre un
escritorio, con una pluma roja en la mano, marcando una columna
interminable de texto, limpiando infinitivos y arreglando
participios y cosas así. Pero el rol editorial y la disciplina
editorial son dos cosas muy distintas. Si bien hay definitivamente
algunas personas que se especializan en esta suerte de trabajo,
usualmente hay mucho más implicado en ser un editor.
En el sentido más amplio, el trabajo de un editor es ayudar a los
escritores a lograr que sus escritos sean más efectivos. Esto
implica gramática y puntuación y selección de palabras, sí, pero una
enorme parte del trabajo de cualquier editor tiene que ver con la
creación de estructuras efectivas. Un editor puede ser responsable
de estructuras en muchas escalas, desde la enciclopedia hasta el
libro de texto, hasta el artículo, hasta el párrafo o hasta la
oración.
Como el editor, el arquitecto de información se ocupa más
fundamentalmente de crear estructuras de información. Pero la
disciplina de la arquitectura de información ve esta responsabilidad
bajo una luz muy diferente. En el mundo de la arquitectura de
información, todos los retos estructurales son variantes del mismo
problema: el problema de la recuperación de información.
La disciplina editorial tiene que luchar también con problemas de
recuperación de información. Muchas publicaciones están
estructuradas para facilitar la recuperación de información: los
directorios telefónicos, los diccionarios, los atlas. Sin embargo,
estas publicaciones son sólo una fracción del volumen incalculable
de material que se publica cada año.
Todas las demás publicaciones (las que no son diccionarios o
atlas) también tienen estructuras. Pero esas estructuras pueden no
reflejar los esquemas de clasificación ordenada que uno espera de
una obra de referencia. Los escritores y editores usan estructura
para lograr varias metas. Algunas estructuras buscan enseñar; otras,
informar; otras más, persuadir.
Yo pienso que la arquitectura de información también puede atacar
este más amplio conjunto de problemas, y que este potencial ya está
latente en la disciplina tal y como se practica hoy día. Creo que el
campo de la arquitectura de información eventualmente llegará más
allá de la esfera de la recuperación de información. Pero nuestro
acercamiento actual no será suficiente para llevar la arquitectura
de información a su potencial pleno.
Si uno le pregunta al editor de una revista o un periódico si la
estructura de su producto fue probada con lectores antes de su
publicación, seguramente se reiría. Para el editor, desarrollar
estructuras efectivas es cuestión de ejercer su juicio profesional:
un juicio afinado por años de prueba y error y por duramente ganada
experiencia en el oficio.
Para él, la prueba de su efectividad en la disciplina es su
capacidad de ejercer dicho juicio. Para él, la idea de abandonar ese
juicio profesional y reformular su papel como un conducto a través
del cual los hallazgos de investigación se convierten en estructuras
sería simplemente absurdo.
¿Y sabe qué? Tiene razón.
Parte 3 de 6: Con ropa de
laboratorio
En las mentes de muchos fuera de nuestra disciplina, la
'arquitectura de información' se ha vuelto sinónimo de 'usabilidad'.
Es fácil comprender por qué los practicantes de una disciplina tan
nueva como la nuestra pueden querer alinearse a una disciplina ya
establecida que ha hecho algunos progresos en la fijación de
credibilidad. Pero al fusionar la arquitectura de información con la
investigación, corremos el riesgo de corromper nuestro proceso y de
minar la propia credibilidad a la que aspiramos.
La moda actual en pensar sobre la arquitectura de información es
que la única arquitectura buena es la que se ha construido sobre un
cimiento de investigación con usuarios anterior al diseño, y que se
ha validado con una ronda subsecuente de pruebas con usuarios. Pero
la integración de arquitectura con investigación --y la conclusión
de que la una no puede existir sin la otra-- es un engañoso exceso
de simplificación.
En el mejor de los casos, estamos simplemente engañando a
nuestros clientes. En el peor, también nos engañamos a nosotros
mismos.
Incrustar nuestras decisiones de arquitectura en una
investigación tiene el efecto de hacerla 'a prueba de balas'. Es
mucho más fácil defender la ciencia que defender una opinión, aunque
se trate de una opinión informada por la experiencia y el juicio
profesional. Pero lo que está ocurriendo aquí en realidad no tiene
nada de ciencia: es pseudociencia. Vestir nuestras opiniones en los
atributos de la investigación no las hace científicas, así como
vestir bata de laboratorio no nos convierte en científicos.
La investigación beneficia a la arquitectura más cuando busca
definir el problema que debemos resolver. La investigación beneficia
a la arquitectura menos --y puede hasta producir malos resultados--
cuando busca definir la propia solución.
No siempre es fácil decir si un estudio de investigación define
un problema o define una solución. Durante el proceso de
investigación, los intentos bien intencionados por articular el
problema pueden convertirse en sugerencias de solución
--especialmente cuando la persona que realiza la investigación
también es responsable de crear la solución.
La estructura de un estudio de investigación puede en sí implicar
cierta solución. Similarmente, el proceso de analizar datos de
investigación para producir hallazgos puede introducir sesgos y
asunciones que dicten una solución dada. Y como estos estudios se
realizan sin el juicio de los pares, nunca salen a relucir los
métodos descompuestos y los hallazgos sesgados.
Aún peor que un estudio de investigación que sugiera
implícitamente una solución es un estudio explícitamente diseñado
para proporcionar una. "Los usuarios nos han dicho cómo organizar la
información: ¡ahora impleméntala!"
La investigación puede ser extremadamente útil en casos en los
que las metas de los usuarios se puedan identificar y medir con
claridad. La recuperación de información es un área donde ocurre
esto; el comercio electrónico es otra. Pero la investigación está
mal equipada para dar cuenta de las metas fuera de estos limitados
dominios.
Incluso el estudio de investigación mejor diseñado no puede
reemplazar a un arquitecto diestro. Todo el propósito de una
arquitectura derivada de una investigación es que nada sorprenda
jamás al usuario. La investigación es perfecta para crear
arquitecturas en las que todo es predecible y familiar. En ciertos
casos, como en la recuperación de información y en el comercio
electrónico, eso es exactamente lo que deseamos.
Pero en muchos casos, la arquitectura debe adaptarse a una
audiencia que no está familiarizada con el asunto en cuestión. Y a
veces, como cuando la meta de la arquitectura es educar o persuadir
a su audiencia, el elemento de sorpresa puede ser una de las
herramientas más efectivas del arquitecto. Pero una arquitectura
derivada directamente de la investigación garantiza que dichas
sorpresas jamás ocurrirán.
Más todavía, quizás nunca podamos descubrir estos nuevos
acercamientos arquitectónicos si nos basamos demasiado fuertemente
en las pruebas de usuario como el medio primario para validar
nuestro trabajo.
Cuando estaba en la secundaria, tomé un curso que ostensiblemente
tenía que ver con habilidades de lenguaje y vocabulario. El primer
día de clases, descubrí que la clase tenía que ver más bien con cómo
ganarle a la SAT [Prueba de Aptitud Académica], la prueba
estandarizada que constituye una de las claves para poder entrar a
la universidad.
No aprendimos principios generales para mejorar nuestro uso del
lenguaje, o nuestro dominio del vocabulario. Lo que sí aprendimos, y
lo que practicamos repetidas veces, fue cómo funcionan las pruebas
de la SAT, cómo se formulan las preguntas y cómo conjeturar con
efectividad cuando no supiéramos la respuesta. Pero ganarle a la
prueba no es lo mismo que conocer el material.
Pasa lo mismo con la usabilidad. Cuando definimos que la prueba
es el determinante final de éxito o fracaso, alentamos la
especialización en el arte de ganarle a la prueba. La ley no escrita
de la usabilidad es que la aproximación más eficiente es la mejor.
Pero de nuevo: fuera del área limitada en que las tareas del usuario
se pueden identificar con facilidad y las metas se pueden reconocer
con rapidez, la eficiencia no es necesariamente un bien universal.
Las pruebas no pueden dar cuenta de todas las metas posibles de un
arquitecto o de sus usuarios.
Si nuestra disciplina sigue desarrollándose por su curso actual,
habremos desarrollado todo un cuerpo de conocimiento sobre la
arquitectura de información que es poco más que un conjunto de tips
y trucos para ganarle a la prueba. Mientras tanto, los problemas
creativos reales inherentes a nuestro trabajo seguirán tan mal
comprendidos como lo están hoy.
Parte 4 de 6: Luego ocurre un
milagro
Hay un cierto tipo de mensaje comúnmente visto en las listas de
correo que se dedican a la arquitectura de información. Dice algo
así como:
"Necesito ayuda. Propuse una solución que todos los de la lista
coinciden en que es totalmente sensata. Pero alguien de mi
organización prefiere otra solución, y todos en la lista coinciden
en que es absolutamente inviable. ¿Conoce alguien alguna
investigación que demuestre que estoy en lo correcto?"
Aquí el verdadero problema no es falta de datos: es falta de
credibilidad. La humillación del arquitecto de información es
continua. Primero tenemos que explicar lo que hacemos. Luego tenemos
que explicar por qué es importante. Luego, una vez que entienden esa
parte, nuestros clientes deciden que ellos también pueden hacerlo.
Después de todo, nada que tenga tan profunda importancia estratégica
debe ser dejado en manos de alguien que no sea un ejecutivo,
¿verdad?
En nuestro esfuerzo por salvar la brecha de credibilidad, nos
hemos vuelto hacia la investigación para que respalde nuestras
recomendaciones. Nuestra impaciencia con nuestra propia capacidad
para desarrollar un sentido de lo que funciona mejor en el nuevo
medio -- combinada con nuestra necesidad de persuadir a quienes no
comprenden nuestro campo -- nos ha conducido a una sobredependencia
respecto a la investigación, para que ésta nos diga qué pensar.
La efectividad percibida de este acercamiento nos ha llevado a
tratar de 'cientifizar' el resto de lo que hacemos, destilando la
arquitectura de información a una simple fórmula, un proceso paso a
paso, un conjunto de reglas. Se han hecho muchos intentos por
codificar un proceso de arquitectura de información. La expectativa
parecer ser que de alguna manera podamos llegar a una aproximación
estándar a la que se alimenten datos de información en un extremo,
de suerte que la arquitectura ideal salga por el otro.
Pero todo intento de articular una metodología para la
arquitectura de información se ve igual: grandes volúmenes de
información sobre métodos preliminares de investigación sobre
usuarios, seguidos por exhaustivos catálogos de técnicas de pruebas
de usabilidad. Pero un momento: ¿acaso no falta algo aquí? ¿Cuándo
es que realmente ocurre el trabajo de arquitectura?
Todo este asunto más bien nos recuerda un famoso cartón de Sydney Harris, en el que un científico está
evaluando el trabajo de otro en un pizarrón. Señala a parte de la
ecuación y dice: "Creo que deberías ser más explícito en el paso
dos". La parte problemática de la ecuación es donde las matemáticas
ceden el paso a una frase que dice: "Entonces ocurre un
milagro..."
En el caso de la AI, el "milagro" es la creación de la
arquitectura misma. Hay un creciente cuerpo de conocimiento sobre la
investigación que nos puede informar este proceso creativo;
similarmente, hay un conjunto establecido de métodos para evaluar
los resultados de este proceso. Pero el proceso mismo --el núcleo de
nuestro trabajo-- sigue siendo un misterio, un tremendo agujero en
nuestra comprensión de la disciplina de la arquitectura de
información.
Pasamos todo nuestro tiempo hablando sobre todo excepto la parte
más importante de lo que hacemos. Irónicamente, nuestro énfasis en
métodos de investigación, que busca mejorar nuestra credibilidad,
sólo la deteriora. La impresión que creamos es la de que cualquier
persona armada con los "Siete pasos a una AI exitosa" puede hacer
nuestro trabajo. No es de extrañar que sintamos que nuestro rol está
en peligro.
Cualquier método que no se aproxime al proceso creativo está
lamentablemente incompleto. Más aún, si seguimos defendiendo
cualquier acercamiento que se base en amplias investigaciones como
la Única Metodología Verdadera, corremos el riesgo de alienar y
excluir a las personas precisas cuya participación necesitamos para
asegurar el crecimiento de la disciplina.
Parte 5 de 6: El arquitecto del
mañana
La especialización, se ha dicho, es cosa de insectos.
Pero fue la especialización la que en realidad ayudó a la
disciplina de la arquitectura de información a consolidarse en los
primeros días de la Web. E incluso ahora, son los especialistas los
que mantienen viva a la disciplina frente a la liquidación
industrial del personal de desarrollo Web extra que contrató durante
los días del boom de la Nueva Economía.
Todos los campos padecen inversiones como la actual. El reto para
los practicantes es evitar estrategias que cumplan necesidades de
corto plazo a expensas del crecimiento a largo plazo del campo.
Nuestra respuesta a las condiciones económicas actuales ha sido
clavarnos en nuestros talones, insistiendo en la importancia
estratégica de los especialistas en AI para los negocios. Este
acercamiento bien podría conservar a algunos de nosotros en sus
posiciones de especialistas un poco más. Pero acentuar la
especialización puede carcomer el progreso de la disciplina, y
mermar cualquier ímpetu que quede de la fiebre del oro.
Aunque el mercado para la disciplina seguirá creciendo en los
años por venir, el mercado para el rol (especializado) siempre
seguirá siendo sólo una pequeña rebanada de aquel mercado mayor.
Los especialistas siempre tendrán una parte qué desempeñar.
Algunas organizaciones tienen tanto trabajo en marcha que tener un
arquitecto de información doméstico será crítico para su éxito.
Algunas organizaciones que usualmente no necesitan recursos de AI
dedicados a veces tendrán proyectos lo bastante grandes o lo
bastante importantes como para requerir la consultoría de un
especialista en AI. Las organizaciones cuyos sitios Web les ayudan a
hacer dinero (más que a ahorrarlo) verán fácilmente el valor que
tiene el desarrollar expertise en AI.
Pero la mayor parte de la gente que hace AI nunca podrá
concentrarse en ella exclusivamente. La mayoría de las
organizaciones nunca tendrá el volumen de trabajo suficiente para
justificar la contratación de un AI doméstico dedicado. Para la
vasta mayoría de las organizaciones, el trabajo de Web siempre será
un centro de costo, no un centro de utilidades. Como resultado, la
mayoría de los equipos tendrán siempre déficit de capacitación,
déficit de personal, y restricciones presupuestarias.
Si tenemos mucha suerte, la responsabilidad por la arquitectura
de información se asignará a alguien de esos equipos. Estas personas
pueden tener títulos de 'diseñador Web' o 'editor de contenido' o
'administrador de proyecto'. Para todos ellos, la experiencia del
usuario es sólo uno de muchos asuntos que deben tratar. Y el trabajo
que hacen constituirá la vasta mayoría de la AI en la Web.
El futuro de la arquitectura de información está en sus manos, no
en las nuestras.
El progreso de la disciplina depende del desarrollo y la
iteración de un cuerpo de conocimiento. Este cuerpo de conocimiento,
a su vez, sólo puede producirse mediante la consideración deliberada
de una amplia gama de problemas arquitectónicos y sus soluciones
potenciales. Lo que necesitamos por encima de todo son buenos casos
de prueba, y las percepciones que nacen de atacarlos
directamente.
Pero como especialistas, tenemos recursos limitados para una
empresa así. ¿Cuántos proyectos puede acometer en un año un solo
especialista? Ciertamente no más de una docena, y en la mayoría de
los casos probablemente muchos menos. Mientras tanto, por cada
especialista muchos más no-especialistas andan por ahí afuera
trabajando aislados, repitiendo los errores de otros, y sin
compartir lo que aprenden con nadie.
A fin de que la disciplina progrese, necesitamos abrir el diálogo
para incluir a estos no-especialistas, para permitirles que
contribuyan al desarrollo de nuestro cuerpo de conocimiento. Pero
esto, a su vez, requiere que admitamos que la disciplina y el rol
estén separados, y que la disciplina pueda ser practicada por
quienes ocupan una amplia variedad de roles.
Además, debemos hacer lo que podamos por apoyar a los
no-especialistas en el trabajo de AI que realizan. Las metodologías
de investigación amplia no les ayudarán, porque no tienen ni los
recursos ni el soporte para implementar estos acercamientos. E
incluso si los tuvieran, dominar la invetigación y las pruebas no
harán de un mal arquitecto un arquitecto bueno. Se requiere algo
más.
Parte 6 de 6: Secretos y
mensajes
A menudo me han preguntado el secreto de mi éxito como arquitecto
de información. Aquí revelaré por primera vez dicho secreto.
Tengo corazonadas.
Claro que no basta con tener corazonadas. Tienen que ser buenas
corazonadas. Mis corazonadas tienen que ser mejores que las
corazonadas de mis clientes: por esa razón me contratan.
Yo le atribuyó la calidad de mis conjeturas a mi formación en
periodismo. Pero no estoy sugiriendo que todo arquitecto de
información asista a la escuela de periodismo, o que cubra un
internado en el diario local. Lo que se necesita es un nuevo
acercamiento, que no esté ligado a ninguna disciplina antigua.
Todo mundo busca la fórmula secreta que elimine la conjetura de
la arquitectura de información. Pero las conjeturas son una parte
inevitable de nuestro trabajo. Y lo que es más importante, es la
calidad de las conjeturas lo que distingue a un arquitecto bueno de
uno malo
Esto no significa que no haya lugar para la investigación en el
proceso de arquitectura de información. La investigación puede
ayudarnos a mejorar nuestras corazonadas. Pero la investigación debe
informar a nuestro juicio profesional, no reemplazarlo.
La metodología de investigación perfecta, arraigada en principios
científicos autorizados de estudios etnográficos, pesquisas
contextuales y pruebas de factores humanos, no le hará el menor bien
a las legiones de no-especialistas que estarán resolviendo la
mayoría de los problemas de arquitectura de información. Lo que esta
gente necesita más que todo son herramientas y técnicas para
ayudarles a mejorar la calidad de sus conjeturas: para ayudarles a
tener mejores corazonadas.
Los practicantes de la AI provienen de una muy diversa gama de
antecedentes, y traen consigo una amplia gama de experiencias para
enfrentar los problemas de arquitectura. Pero pese a todas nuestras
diferencias, hay algo en lo que podemos estar de acuerdo: el mundo
necesita mejores arquitecturas.
Los datos de investigación y las metodologías formalizadas no
garantizan mejores arquitecturas. Los mejores arquitectos garantizan
mejores arquitecturas. Pero nada de lo que estamos haciendo ahora
conducirá a una generación de mejores arquitectos.
Si seguimos trabajando desde una definición de la arquitectura de
información que requiere la ejecución por un especialista, la
disciplina se estancará y morirá. Actualmente, estamos construyendo
un cuerpo de conocimiento cuyos requerimientos básicos -- un
especialista dedicado, mucho tiempo y dinero dedicados a la
investigación -- excluyen en automático a la vasta mayoría de casos
del mundo real. Este acercamiento condenará a los especialistas a
una irrelevancia creciente, conforme nos desconectemos más y más del
modo en que ocurre la arquitectura real.
Como el editor de revistas, el arquitecto de mañana no dispone
del lujo de semanas y semanas para diseñar y probar iterativamente
una solución. Necesita resultados inmediatos. Necesita mejores
corazonadas. Nosotros, como una comunidad con un interés vital en
mantener viva la disciplina, deberíamos estar ayudándoles a
desarrollar las habilidades que les darán esas mejores corazonadas.
Herramientas para pensar, no fórmulas secretas. Habilidades, no
reglas.
Para crear reglas que puedan aplicarse ampliamente, debemos
desarrollar una más profunda comprensión del pensamiento creativo
implicado en nuestro trabajo. Luego, habiendo proporcionado esas
herramientas, debemos también proporcionar medios para que los
no-especialistas se unan a nuestras filas -- de nuevo, acentuando
las habilidades demostradas por encima del mero conocimiento de
métodos. Estas personas serán la fuente más fértil de nuevas ideas
en nuestro campo, y debemos cultivar su participación.
Los negocios -- los tomadores de decisiones por cuyo
consentimiento nuestra disciplina se practica -- han salido
tropezando de la montaña rusa de la Nueva Economía y se sienten un
poco mareados. Demasiada gente les ofreció aceite de víbora como
tónico curativo.
Esto nos presenta una oportunidad única. Las opciones que
elijamos ahora conformarán la percepción de nuestro campo y las
direcciones que tendremos disponibles en el futuro.
El mensaje correcto, el que sea honesto y persuasivo, nos traerá
la credibilidad que buscamos y el respeto que merecemos. El mensaje
equivocado -- el que acentúa la pseudociencia por encima del juicio
profesional aplicado, o el que quiere decirles a los ejecutivos cómo
manejar sus compañías -- sólo nos conducirá a una continua
frustración.
El mensaje que deberíamos estar enviando es el siguiente:
La arquitectura de información es una disciplina que puede ser
practicada por personas que cumplen una amplia gama de roles. Pueden
diseñarse arquitecturas para lograr una amplia variedad de metas, no
sólo la recuperación de información. El factor individual más
importante en el éxito de una arquitectura es la destreza de su
creador. Esta destreza se aplica a través de una combinación de
juicio profesional experimentado, de la consideración juiciosa de
los hallazgos de investigación y de una creatividad disciplinada.
Esta destreza puede ser desarrollada y aplicada por igual por
especialistas y no-especialistas.
Sólo siendo honestos con nosotros mismos acerca de lo que nos
hace valiosos podremos convencer a otros de ese valor. Sólo siendo
generosos con nuestro conocimiento podremos cosechar todos sus
beneficios. Y sólo creando una cultura en la que estos principios
sean plenamente asimilados podemos alentar el crecimiento de nuestro
campo y asegurar la continuación de nuestro éxito.
© 2002 Jesse James Garrett
This document: http://www.jjg.net/ia/recon/espanol.html
More
IA resources: http://www.jjg.net/ia/