Me gustar�a retomar el tema de resolver problemas para comentar no algo especifico sobre la relaci�n entre dise�adores y AI, sino sobre dise�o. Algunos mensajes han apuntado hacia que dise�o es mayormente funcionalidad pero desde mi punto de vista es algo mas profundo y complejo. Por lo que me gustar�a exponer mi punto de vista del dise�o. Para ello me basare en el siguiente articulo: Krippendorff, K (1989) ?On essential contexts of artifacts or on the proposition that ?Design is making sense (of things)? Design Issues, 5(2), pp. 9-39
Este articulo de Klaus Krippendorff esta basado en el dise�o de producto, pero del que se puede sacar una idea general de dise�o. En el articulo habla de la sem�ntica de producto que esta formada por lo que el objeto es (en este caso forma) y su significado. En este texto Klaus sugiere que los objetos son percibidos como significados: ?... people do not perceive pure forms, unrelated objects, or things as such but as meanings. The distinction between what an object is and what that object means to somebody may not be demonstrable as far as perceptual data are concerned. The above answers suggest that objects are always seen in context (of other things, ituations, and users, including the observing self):? (Krippendorff: 1989: 12) Luego en el articulo desarrolla cuatro contextos con los que sugiere explicar el dise�o: (solo escribo el enunciado) "Operational context, in which people are seen as interacting with artifacts in use. Sociolinguistic context, in which people are seen as communicating with each other about particular artifacts, their uses and users, and thereby co-constructing realities of which objects become constitutive parts. Context of genesis, in which designers producers, distributors, users, and others are seen as participating in creating and consuming artifacts and as differentially contributing to the technical organization of culture and material entropy. Ecological context, in which populations of artifacts are seen as interacting with one another and contributing to the autopoiesis (self-production) of technology and culture.? (Krippendorff: 1989: 12) En el mismo articulo Klaus sugiere que la forma no sigue la funci�n sino el significado. Como antes he comentado este articulo esta enfocado el dise�o industrial. Pero la diferencia a grandes rasgo con los servicios (desde mi punto de vista) seria que en vez de hablar de formas hablar�amos de historias (forma + comportamiento + contenido / tiempo). Desde mi punto de vista: El dise�o se basa en la integraci�n entre el entendimiento de lo que el objeto, servicio, ambiente,...significa y la construcci�n de lo que es, para crear objetos, servicios, ambientes... que tengan sentido. Roberto Bolullo bolullo.com/roberto Javier Ca�ada wrote: Estoy muy de acuerdo con Oscar, especialmente cuando destaca que el dise�o es, sobretodo, funcionalidad. Yo siempre he pensado que la arquitectura de informaci�n es dise�o, puesto que se construyen objetos orientados a solucionar necesidades. Siendo as�, la diferencia entre el que llamar�amos "dise�ador" y el AI se reduce a que uno se encarga de los aspectos funcionales y el otro de los sensoriales. Eso deja bastante claro que es perfectamente factible que una misma persona haga las dos cosas en proyectos sencillos, donde no haya mucha investigaci�n con usuarios. Ocurre que muy a menudo s�lo se habla de webs de contenidos, donde no hay apenas funcionalidad. En esos casos es l�gico y habitual que el rol del AI y el del director de arte (por no llamarle dise�ador) compitan. Sin embargo, hay tanto de estandarizaci�n en las webs de contenidos, que la labor del AI se reduce a la taxonom�a y a apoyar en el dise�o de informaci�n de posibles diagramas o charts. Para mi es mucho m�s importante centrarse en el dise�o de aplicaciones on u offline, donde se ve m�s claro el rol de cada uno. S�lo hay que pensar en sistemas de mensajer�a, intranets, banca, etc. para ver cl�ramente d�nde est� cada uno. A todo esto, ayer di por casualidad un art�culo que precisamente habla del tema. Es algo simplista, y desprecia un poco el rol del directoe de arte, pero deja algunas cosas claras: http://www-106.ibm.com/developerworks/usability/library/us-inarch.html un saludo. __________________________________ Javier Ca�ada Cresp� Human-Computer Interaction Team IconMedialab Iberia tel. +34 91210080 fax. +34 915228220 -----Mensaje original----- De: Oscar Reales [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 12 de julio de 2002 18:55 Para: Lista de Cadius Asunto: [cadius] Re: donde se resuelven problemas... Este tema de quien tiene la �ltima palabra sobre donde va o deja de ir un bot�n, es extremamente complicado, al menos en la practica profesional que a mi me toca vivir (y entiendo que a m�s de uno de los componentes de esta lista). En primer lugar, si hablamos de DISE�O, y solamente de esto, el asunto no esta del todo claro: En el mundo del dise�o (no me refiero a "dise�o web" sino al dise�o gr�fico tradicional) los dise�adores han tenido que afrontar el hecho de que todo el mundo ten�a una opini�n (profana) sobre sus trabajos y la calidad de los mismos: "cambiame este color de fondo que no me gusta...", "... Al cliente no le gusta ese tipo de letra, o prefiere un fondo azul, o quiere meter la fotograf�a de la f�brica", "lo queremos en amarillo, porque el amarillo vende....", etc. La mayor�a de estas opiniones se vierten basadas en la creencia popular de que el dise�o es poco cient�fico y muy art�stico, basado en los gustos y criterios est�ticos (particulares) del dise�ador en cuesti�n. Nada m�s incierto, aunque algunos dise�adores (a lo mejor muchos) han alimentado esa corriente de opini�n justificando sus trabajos o las decisiones tomadas en sus dise�os con razones como: "utilizo esa tipograf�a por que me gusta y queda bien", "ese color azul es muy bonito...", etc. Claro, cuando uno justifica un trabajo bas�ndose en lo que le gusta o lo que no, tal vez por incapacidad para explicar con otros razonamientos el desarrollo de su trabajo, tiene que enfrentarse a que a la persona que esta enfrente no le guste. Y si el que esta enfrente es el cliente, que gusto se acabar� imponiendo???, da igual, si el dise�o final aprobado es consecuencia de un gusto particular algo ha fallado en el dise�o. El dise�o es, entre otras cosas funcionalidad, y en cualquier caso no es un arte, aunque haga uso de esta para conseguir su finalidad. Por tanto, cualquier "defensa" de un trabajo tiene que argumentarse con criterios objetivos: "si este boton lo cambiamos de sitio, ser� menos visible, o romper�amos el orden visual", "Si utilizamos esa tipograf�a es porque resulta m�s legible y permite ser leida sin dificultad por personas mayores de 60 a�os, que es el p�blico al que nos dirigimos...", "el color de fondo aporta un contraste visual que permite destacar la informaci�n...", etc... Si esto ocurriera as� m�s veces, ser�an menos las ocasiones en que un gusto personal acaba imponi�ndose y el trabajo final ser�a mejor. Si aplicamos esta teor�a al dise�o web, entonces no debe de existir problema entre el arquitecto de la informaci�n y el dise�ador: El dise�ador argumenta su trabajo (con criterios l�gicos y justificaciones m�s alla del gusto est�tico particular) y el arquitecto (que debe conocer las dificultades del dise�ador y de su trabajo, as� como el de otras areas relacionadas), puede dialogar y proponer soluciones alternativas, igualmente justificadas y basadas en criterios l�gicos y no en gustos particulares. El resultado final debe ser un trabajo fruto de la labor concienzuda de 2 profesionales que luchan por conseguir un objetivo com�n. En ese caso, la lucha por posicionar un bot�n es anecd�tica. A mi entender el problema radica en que hay mucho DISE�ADOR autoproclamado (alguno hasta con su carrera de bellas artes) que no entienden realmente que es el dise�o (en general) y mucho menos que tiene el dise�o que aportar en el desarrollo de un sitio web. En general, cuando un "dise�ador" utiliza las palabras "me gusta...", "queda bien...", "es bonito...", etc., malo. En esas circunstancias, al jefe o responsable final de proyecto no le quedan m�s que dos soluciones: Aceptar la soluci�n propuesta o imponer un cambio, ya que no se puede discutir ni razonar sobre gustos particulares. El arquitecto de la informaci�n tiene una visi�n global del sitio, ya que su disciplina afecta a gran parte de las �reas de desarrollo de un proyecto. En consecuencia, un buen arquitecto tiene que saber de dise�o (entre otras cosas). Que ocurre cuando dos personas entienden de lo que est�n hablando?: que pueden discutir, razonar y alcanzar puntos de acuerdo sobre la materia. Mi reflexi�n final es que, un buen dise�ador y un buen arquitecto de la informaci�n, solo pueden acabar entendi�ndose, ya que ambos persiguen un objetivo com�n, y la labor de uno complementa la del otra. La realidad, sin embargo, me dice que el dise�ador ve en el arquitecto un enemigo, alguien que se entromete en su parcela y no respeta mucho esta figura y que el arquitecto de la informaci�n ve en el dise�ador una persona poco sensibilizada hacia la usabilidad y la funcionalidad y que encaja con dificultad los cambios planteados en el dise�o. ��qui�n de los dos debe tener la �ltima palabra??, si de mi dependiera y en general dir�a que el Arquitecto de la informaci�n, ya que, si tiene el perfil que considero id�neo, tendr� conocimientos (posiblemente amplios ya que muchos arquitectos vienen del dise�o) de DISE�O, pero tendr� una visi�n mucho m�s "amplia" del proyecto final. De la opini�n del cliente no hablo, porque creo que la de este no tiene (o no debiera de tener) la menor importancia en las decisiones de desarrollo. EL cliente debe preocuparse del negocio, de la estrateg�a, de los objetivos que persigue y dejar el como a los profesionales. ��cu�ntos de nosotros le decimos al fontanero como tiene que poner una tuber�a??, o al electricista por donde tienen que pasar los cables??. Yo por lo menos, me limito a decir quiero un enchufe aqu� o quiero un grifo all�. __________________________________________ Est�s suscrito a Cadius como: [EMAIL PROTECTED] Si quieres darte de baja o modificar tu suscripci�n, puedes hacerlo desde http://www.cadius.org/forms/login.html __________________________________________ Est�s suscrito a Cadius como: [EMAIL PROTECTED] Si quieres darte de baja o modificar tu suscripci�n, puedes hacerlo desde http://www.cadius.org/forms/login.html
