Archivo de la categoría "Hci"

Esko Kurvinen say:

Friday, 27 de May de 2011

    Comillas 2.0 … the activity of industrial design is a hard nut to crack. Design work is creative, innovative – artistic even – and often goes hand in hand with cutting-edge technological developments. Like any future-oriented activity, the process itself and especially the quality and commercial success of the outcome are highly unpredictable. At best, organizations can create favorable conditions and construct processes for design activities, but the creative process – as we often want to call it – has largely remained a black box.
    Article 1 contributes to our understanding of design work by looking at what designers do as part of a development team. This means studying design as a particular type of problem-solving involving an interdisciplinary team of experts. In addition to the academic discussion on industrial design, the study also has local implications for the parties involved. This approach is in line with the general philosophy of organization development; using the best ethnographic practices to describe and make work visible to the participants, who are then themselves better equipped to adjust their work processes…Comillas 2.0

    in Prototyping social action

    Investigación Remota. Evento UPA Madrid. 10 de mayo 2011

    Thursday, 28 de April de 2011

      ¿Estas interesado en conocer más sobre Remote Research? Entonces no te puedes perder la charla que ha organizado UPA Madrid el día 10 de mayo a las 19h en el Auditorio Fundación Alfonso Martín Escudero, en Avenida de Brasil, nº30.

      La charla se llama “¿Cómo medir el comportamiento de los usuarios de manera presencial y online?” y constara de una parte teórica sobre el RR y una parte practica en la que se hará una demostración explicación de las herramientas UserZoom y Userlytics con turno de preguntas.

      Las plazas son limitas. Si te quieres apuntar o ampliar la información visita http://bit.ly/upamadrid

      ¿Eres moderno y no sabes como llegar? QRcode del mapa.

      Mapa a Auditorio Fundación Alfonso Martín Escudero.

      Hastag: #upamadrid, #remoteresearch

      OFFF Madrid 2011

      Sunday, 20 de March de 2011

        El OFFF es un festival de cultura postdigital.

        Por cultura postdigital  hay que entender cualquier producción cultural producida con ayuda de ordenadores. Es una buena ocasión para conocer la vertiente mas artística de los interfaces y del diseño. Y si vives en Madrid es una muy buena ocasión para asistir a un festival internacional pudiendo volver a dormir a casa.

        La edición 2011 se celebra en Barcelona, pero durante mayo algunos eventos se realizan en Madrid  dentro del Offf on tour.  Las citas:

        • Del 18 al 27 de mayo en Gloria Gallery podrás ver muestras de trabajos.
        • El día 19 mayo en el CBA la jornada de conferencias, necesitas ticket que cuesta 25 27,75€
        • Y del 23 al 26 de mayo talleres en La Casa Encendida.

        La info completa en su web  offf 2011 madrid
        Y en twitter  @offfest.

        Los sitemap son contenido

        Wednesday, 22 de December de 2010

          Desambiguazión: Este post no habla de sitemap en XML para posicionamiento en buscadores.

          Los Sitemaps son diagramas que representan los contenidos del site.
          Vale, parece sencillo, este es nuestro Sitemap, un diagrama que dice aquí van “los servicios”, aquí “quieres somos”, aquí el “blog”…
          Pero esta idea se complica cuando se incluye la variable “navegación”.  El Sitemap puede dar una idea de cómo se llega a un sitio, cual es la relación entre las distintas pantallas (¿páginas del site? ¿contenidos?). Pero la navegación se debe resolver en otro documento que se llama Task Flow. Llevar a cabo un Task Flow nos obliga a identificar objetivos de los usuarios (Investigación) y que diseñemos para lo probable y no para todo lo posible.
          Volviendo a los Sitemap. Para iniciar el Sitemap hay que tomar una decisión. Y esa decisión responde a ¿Cómo se va a enfrentar el equipo al proyecto?.
          Podemos elegir entre a un nivel muy alto de detalle, donde se van a modelar todas las pantallas y todas las interacciones y microinteraciones, vamos a llamar a esto Enfoque A.  O un enfoque modular, donde vamos a descomponer los componentes de las pantallas en módulos reutilizables. Vamos a llamar a este otro Enfoque B.

          Estas consideraciones pueden influir mucho sobre como se va a desarrollar el proyecto, y se suelen dejar al gusto del “prototipador” que las puede tomar de una forma inconsciente. (Además de que no le compete a él tomar estas decisiones).

          El enfoque A consume mucho más tiempo en prototipar, y se suele emplear en proyectos pequeños. Tiene como punto negativo que hace que lo importante se diluya entre la cantidad y genera la sensación de documentación al peso.

          El enfoque B es mucho más participativo y esta más orientado a equipos de desarrollo,  se suele emplear en proyectos grandes donde hay varias personas implicadas en el diseño de los wireframes. Como punto negativo tiene un nivel de abstracción mucho más elevado que dificulta su consumo por el cliente, pero permite una ejecución mucho más ágil.

          Algo tan asumible como en principio es un Sitemap puede determinar como se va desarrollar el proyecto.

          Para leer más sobre Sitemap (y entregables)

          Test remotos de usabilidad

          Wednesday, 24 de November de 2010

            ¿Qué son?

            Test remotos de usabilidad o Remote Research (RR) es una forma de aplicar test usabilidad* con usuarios sin que el evaluador se encuentre físicamente en el mismo espacio que el participante.
            Los test de usabilidad se pueden agrupar en dos grandes grupos en función de la localización del participante y evaluador.
            Si el participante y el evaluador se encuentran en el mismo lugar, los test son presenciales o de laboratorio.

            En cambio si el participante y el evaluador se encuentran en lugares diferentes son test  remotos o remote reseach.
            Los RR pueden así mismo agruparse en distintas categorías**, por ejemplo en función de la participación del moderador podemos tener test moderados y test automatizados por una herramienta. Además, los moderados son de corte más cualitativo, mientras que los automatizados son más cuantitativos.

            En función de la captación del participante y la forma de hacerlo podemos hablar de captación en vivo, mediante un layer, captación por perfil y mediante agencia de captación, contactos personales  o paneles de investigación.

            E incluso en función de la tecnología empleada en las herramientas de captación remota podríamos agrupar en función de las que usan JavaScript y las que usan tecnologías Html.

            Ventajas de RR vs Laboratorio

            La ventaja principal entre los RR y lo test de laboratorio son los costes, entorno a un 42% más barato mediante RR. Este ahorro viene de reducir el tiempo de ejecución y el tiempo de captación de los participantes.
            Además los RR poseen una mayor variedad en la procedencia de las muestras, ya que los RR son virtualmente aplicables a cualquier persona del mundo con una conexión.
            Algunos caso de estudio otorgan unos valores de éxito mayores a los RR. Si se realiza el test en Laboratorio y en Remoto suelen detectarse entorno a 15 resistencias al uso con el RR que pasan desapercibidas en el laboratorio. Pero estas tasa de éxito no son valores concluyentes, así que no vincules tu elección a ello.

            Inconvenientes de RR vs Laboratorio

            Para mí el principal inconveniente está en la falta de especialización en las herramientas y en la técnica. Los RR aun no forman parte del arsenal metodológico de los profesionales, aunque muchas de estas herramientas son gratuitas.

            Si estas interesado en potenciar tus conocimientos en RR y probar alguna herramienta consulta el fantástico el documento de Liz Bacon en referencias.

            bullet.gif Referencias:

            * Diga Test de Usabilidad, NO test de usuarios
            ** Otras categorías sobre las herramientas de investigación en Remote Usability

            Mis técnicas de wireframing

            Wednesday, 27 de October de 2010

              La literatura sobre wireframing es muy limitada, y la mayoría de las referencias suelen ser blog, lo que atomiza este conocimiento, que ademas se suele adquirir mediante la experiencia.

              En la mayoría de los casos estas referencias se suele centrar en el uso de un determinado software, más que en ciertos principios básicos de la técnica.

              Se acepta dentro de las profesiones relacionadas con el diseño de productos digitales en mayor o menor medida que wireframe* y prototipo son sinónimos. De forma absoluta esto no es correcto. Wireframe toma su nombre de las estructuras alambicas que se emplean en el diseño industrial y mecánico. Mientras que el prototipo es una versión alfa de un producto que presenta múltiples finalidades, como es analizar costes antes de su producción, servir para testeó y evaluación o la captación comercial y financiación.

              Cuando yo me tengo que enfrentar a un proyecto en el cual debo realizar wireframes sigo una serie de acciones que creo que me simplifican la vida.

              Mis pasos durante el wireframing:

              #1. Papel. Empezar realizando la composición del producto en papel. Esta idea supongo que no es nueva para nadie, pero creo que es bueno decirlo porque tengo la sensación de que hay prejuicios sobre hacerlo porque se percibe como una actividad no-seria el dedicar una mañana a dibujar interfaces.

              ¿Qué gano haciendo esto? En primer lugar tomar conciencia de los posibles enfoques y necesidades de la solución. Te permite tener en mente un foto a gran nivel de lo que quieres hacer. De esta forma es más sencillo que elijas la herramienta con la que vas a realizar el entregable y como hacerlo y que preveas el tiempo y esfuerzo que implica.

              #2. Unifica las pantallas. Una vez que sabes lo que quieres hacer, una forma cómoda de trabajar es creándote componentes y re-utilizándolos a lo largo de todo el documento. Esta re-utilización puede ser creándote una página maestra o varias, en función de tus necesidades, o creándote galerías de componentes.

              Por página maestra me refiero a un fondo de Visio, un lienzo de OmniGraffle o un master de Axure que puedas necesitar en múltiples paginas de tu documento.

              Existen muchas galerías de componentes. Lo normal es que partas de alguna popular, la adaptes a tus necesidades y se acabe convirtiendo en tu galería.

              ¿Qué ganas haciendo esto? Al usar paginas maestras evitas que los elementos constantes te “bailen” en el PDF, que los cambios estructurales sean mucho más ágiles, por ejemplo cambiar un disclaimer en el pie en un documento de 40 páginas puede ser un poco pesado si hay que hacerlo 40 veces.

              #3. Poner titulo al documento nada más empezar. Y configurar los settings de tu programa con auto-salvado cada 15 minutos. A veces una mañana de trabajo se pierde de forma accidental y resulta muy frustrarte.

              ¿Qué ganas haciendo esto? Paz mental, hay veces que tiraría el ordenador por la ventana, pero saber que en el peor de los casos pierdo 15 minutos me ayuda a mantener la calma. La contrapartida a la seguridad es la libertad, y se hace pesado en según que programa las pausas para que se salve, pero eso es un tema muy personal.

              #4. Guárdate un día para que brille. Por definición un trabajo te lleva lo que crees que vas a tardar, más lo que no sabes que vas a tardar por lo que se pone un tiempo de margen. El diablo esta en los detalles y los detalles consumen mucho tiempo.

              No se si estas tácticas son comunes, supongo que cada maestrillo tiene su librillo. Seguramente parte de esta situación se deba a la ausencia de una metodología proyectual. Espero que estos pasos sean de utilidad para alguien.

              *Wireframe: A wireframe is a visual illustration of one Web page. It is meant to show all of the items that are included on a particular page, without defining the look and feel (or graphic design). It’s simply meant to illustrate the features, content and links that need to appear on a page so that your design team can mock up a visual interface and your programmers understand the page features and how they are supposed to work.

              En usability.gov

              Creative Commons License
              Esta obra está bajo una licencia de Creative Commons.