Archivo de la categoría "Metodologia"

Summer reading list

Tuesday, 4 de August de 2009

    Summer arrives and with it a little free time. It is a good time in our recommended reading list for the holidays.

    Here comme everybody

    The first book is HERE COMES EVERYBODY (How Change Happens When People Come Together) by Clasy Shirky, about people and technology interact as both at the social level, as this affects relationships, the job and media. A lot of views is really useful.

    Stumbling on happiness.

    The second book is STUMBLING ON HAPPINESS by Dan (iel) Gilbert a tour of how the human mind, emotions and decisions, with a very enjoyable and easy to read. Very interesting.

    MODULAR WEB DESIGN

    The third book is MODULAR WEB DESIGN by Nathan Curtis, if you think that something can be improved in the way of working your team, this is your reading. The book is about how to perform prototyping and documentation in an efficient manner within a development team. The typical book that I always think that we need to write.

    Enjoy your summer time and your readings.

    Del User Center Design al Design Thinking

    Monday, 20 de July de 2009

      Comillas 2.0 Design Thinking is the New BlackComillas 2.0

              en Subject to change. Adaptive Path Crew.

      El Design Thinking se este convirtiendo en la nueva palabra de moda. Pero si nos abstraemos de lo prejuicios que pueden acarrear esta notoriedad puede que encontremos  un método útil para lograr productos mucho más eficientes y satisfactorios.

      Además si le prestamos un poco de atención  veremos que mantiene muchos puntos en común con el  Diseño Centrado en el Usuario. Aunque el Design Thinking presta una especial atención a investigación, con acento en la investigación antropológica.

      No existe una definición formal aceptada por la totalidad de la industria, pero mayoritariamente el Design Thinking se define como  una metodología de resolución de problemas, y de detección y descubrimiento de nuevas oportunidades (productos, soluciones, estrategias…) por lo que se puede aplicar a múltiples campos.

      Esta capacidad de detección hace del Design Thinking se haya incluido en  los planes de estudio de muchas escuelas de negocios, y parte de la capacidad de “buzzword” que tiene la palabra proviene de ahí.

      Sin entrar en estos aspectos valorativos, en este post vamos a tratar de mostrar como emplear el Design Thinking en un proyecto.

      Básicamente, si pretendes aplicar el  Design thinking en un proyecto debes llevar a cabo un proceso similar al siguiente:

      #1 Definición de la necesidad: el problema del conocimiento es uno de los principales causas de que un diseño se convierte en un mal diseño. La elaboración del  brief es una actividad  capital, si no sabes que necesitas resolver, con que cuentas y que se espera obtener al final, tu proyecto tiene muchas posibilidades de entrar en espirales hacia ningún sitio. (¿Recuerdas ese proyecto en el que no se avanzaba, que solo había reuniones de las que siempre salías con un cambio nuevo, y que estuvo a punto de que retomaras la senda de instalador de calderas, como te recomendó tu tía-abuela? Todos estos problemas  seguramente provengan de un mal briefing)  En esta fase debes lograr identificar cuales son las preguntas que se deben responder.

      #2 Investigación: Muy bien. Ya sabemos que necesidad necesita resolver el cliente, ahora necesitamos conocer a los usuarios. Tenemos preguntas que resolver. El Design Thinking aboga por la observación como modo de investigación. Para ello parte de la premisa que las “técnicas descriptivas” comprometen los resultados, ya que la figura del moderador puede condicionar los resultados, y los usuarios experimentales pueden presentar motivaciones que generen relaciones espurias.

      #3 Idealización: conoces las necesidades (1), tienes las respuestas (2), pero nadie dijo que solo hubiera una forma de hacer coincidir ambas cosas. De hecho, es posible que encuentres múltiples posibles soluciones a un mismo problema. Parece que la forma más eficiente de enfrentarlo es mediante un equipo. Este enfoque aboga por la eficiencia de 5 personas trabajando 1 día sobre un mismo problema, que 1 persona trabajando 5 días. De los equipos multidisciplinares  suelen salir muchas ideas interesantes. ¿Por qué no hacer un Frankenstein con las mejores?

      #4 Prototipado: Habitualmente desde Diseño Centrado en el Usuario se prototipa la idea vencedora. El Design Thinking aboga por prototipar el set de ideas vencedoras del proceso de idealización y testarlas. Si las cosas no salen como deben, regresa al paso anterior y vuelve a probar.

      #5. Elección: en función de los datos debería ser sencillo elegir la mejor Frankenstein-Idea. Además ya la has probado, por lo que seguramente puedes aportar información de utilidad para campaña de promoción del producto.

      #6. Implematación: Es hora de elaborar tu producto… aquí sigues el ciclo normal de un proyecto, con la metodología propia de la casa (existen muchas filosofías de desarrollo cada una con sus virtudes y defectos).

      #7. Aprendizaje: después de todos estos pasos, no te olvides de documentar. ¿Qué se documenta? Todo el aprendizaje que has obtenido en el proyecto. Por ejemplo si has empleado una técnica de Rol Play basada en simular “un día en la vida del usuario” y has detectado que la técnica funciona mejor si  se graba en vídeo, documéntalo para futuras referencias.

      ¿Porque esta metodología?

      Porque esta forma de abordar los proyectos nos lleva a enfrentar la “CREENCIA” y la “OPINIÓN” con la “OBSERVACIÓN” y el “ANÁLISIS”. Es decir, no diseñas por que el (…Cliente, Diseñador, Equipo …) “CREE” que los usuarios hacen, necesitan o quieren  sino por que tienes “DATOS” de lo que los usuarios hacen, necesitan y quieren del producto.

      Porque si hechas en falta análisis e investigación en tus proyectos  puede ser la solución, al establecer estas necesidades dentro del management del proyecto.

      Así, se puede concluir que la principian diferencia entre el Diseño Centrado en el Usuario y el Design Thinking es  que se  ha pasado de una técnica de diseño a una estrategia de negocio. Aunque ambas presentan un enfoque similar y compatible.

      bullet.gif Referencias:

      Personas. Utility Vs. Representativity

      Saturday, 20 de June de 2009

        Reserch logo

        The design technique of persona is useful in the design of successful products. This tool lets you align the needs and expectations of the product of all those involved in development. They are involved both the coreteam of product, also stakeholders and hippos. In addition to using characters prevents deviations of the goals of product design.

        Because, the persona´s technical should be mandatory in all development.
        Although, sometimes you can find difficulties to personas be accepted.

        The difficulties may come from the nature of the persona because they are abstractions, although based on real data, but do not represent an real users with name and a surname, but the persona have it. (For more information about the technique see Persona y scenarios. A methodology introduction (SP))

        This feature makes that sometimes arise opinions about the appropriateness of the use of persona, and there are doubts about its pragmatism over the use of real users, which may seem more logical in principle, but as we shall see below that it is less efficient .

        The personas are part of the tactic of development, while potential customers are a strategic element of the product.

        The main idea is that the persona do not represent a particular user as such, but are composed of many of the personas of potential users. To these characteristics we call “variables”.
        The personas are abstractions, but are based on data.
        Do not you have to invent, there is a preliminary analysis and investigation. Otherwise you will not do.

        We should not confuse “everybody can use it” in terms of usability with “everybody want use it” in marketing terms. Sometimes the discussions about the appropriateness of the use of personas is thinking about how to influence marketing. And that is also wrong.

        There may be a relationship between personas and real users, but is not a direct relationship between personas and users or customers, but the personas are related by the users through the product variables.

        A persona is composed of variables, a more variable´s personas it reasonable to assume that there will be a smaller number of real users that fit the character. This is one of the reasons why the characters are used. Greatly simplify the process by allowing us to work with multiple variables at once. It also keeps the user selection and recruitment, which can be extremely complex for some variables.

        This relationship is representative of one of the factors that you can not establish a direct relationship. Since more detailed level of the least number of personas that fit real people in them.
        This also explains why the convenience of designing the product for the principal persona.
        Could almost say that when a persona is well developed, should not allow us to identify a specific individual, but should remind us of many traits.

        Therefore one might think that knowing the variables, we could save the job of developing personas. But on the design variables in a ungroup the persona were difficult to establish use cases, which diminishes the efficiency process. The human we are better able to establish empathic relationships when we reach the place of another “person” (though it is imaginary) that when we do it directly from the variables.

        Let’s see this implemented in a classic example of characters taken from the Paper,Personas, Participatory Design and Product Development:An Infrastructure for Engagement of Grudin and Pruitt.

        This paper defines a persona with a high degree of detail. For example “Patrick” is defined in 21 different variables, if the possibility of a potential user has an attribute that is either is 50%, about 21 variables as a result gives us a 0.000047% of real people who fit as Patrick has defined, which for a population like the U.S. at 2009 is 146 real people.

        This is calculated as follows:

        (0.5) ^21 *100%= 0.000047%

        (306,711,000*0.000047)/100= 146

        Now, if we define to allow team Patrick and establish a relationship with him that the product is designed with “Patrick in the mind” design decisions will be more constant and consistent throughout the process, that if link to a list of variables that can be interpreted differently by different teams of agents.
        It also seems easier and cheaper to find people that use “user type” meeting with the desired characteristics, and implications in the design process.

        Conclusion

        • The personas are a design tool that allows the goals of the product remain constant, making products more consistent. This is the purpose of the technique, and you should not forgotten .
        • You can not expect to link users with the personas in a linear fashion, why not have the same kind, the comparisons should be set on variables where necessary. Here is where I believe that this error of Chapman and Milham, who in his paper “The Personas´ New Clothes:Methodological and Practical Arguments against a Popular Method” with an argument based on the calculations outlined above indicate that the technique is wrong because personas can not connect with real users.
        • And if you replace the potential users (customers) by characters is a mistake, that the target will see significantly reduced to dangerous levels and lack of business sense.
        • Recently the technique has been tested on the personas design of a product that reduces discovering the shortcomings identified through usability heuristic analysis between 2 and 4 times less when using the technique of characters.

        bullet.gif References:

        Personas Template in Visio

        Wednesday, 27 de May de 2009

          The technique of personas, identifying the reasons for use, expectations and success of a design. It is a very useful tool, that helps us think needs a single person and not a group, although the character represents a whole is significant and needs, making products more efficient.
          The use of “personas” is included in the methodology of user-centred design (UCD), and if you are using in your designs help define a more efficient structure, functionality and navigation. It will also be useful to discuss aspects of design and product promotion.

          The technique of “persons” works better if integrated into a research strategy, as an ethnographic analysis, a focus group or market research, as this technique is not a single method. So before you start make sure you have enough information to define your “personas”.

          And if you want to start using it already, here you can download this template for personas. (341kb zip).

          The template is in Visio format and consists of a template for the document stencil of the elements and a collection of photos 50’sy some style today, all editable to suit your needs. And the legendary macro copy page, so your job easier.

          Template personajes

          Click on the image for enlarge.

          bullet.gif References:

          Diseño centrado en el usuario e investigación

          Monday, 23 de March de 2009

            ¿En qué consiste?

            El Diseño centrado en el usuario se basa en colocar las necesidades, deseo y limitaciones del usuario(S) en el centro de cada fase del diseño.

            Esto quiere decir que cada una de las decisiones que tomamos a la hora de afrontar el diseño responden a una necesidad hipotética de nuestros usuarios.
            Pero para poder tomar decisiones de diseño respondiendo a las necesidades de los usuarios, parece razonable pensar que en primer lugar debo conocer estas necesidades.
            Así que básicamente el UCD es sinónimo de investigación con usuarios.
            Es curioso que el concepto centre el diseño en el usuario, y no en Los UsuarioS.
            Así partimos de hipótesis, que se pueden basar en datos o en algún otro tipo de conocimiento (suposiciones, experiencias previas, brujería…) en este estado resulta interesante el empleo de Personajes y escenarios, ya que la técnica se presta para teorizar e ilustrar las tipologías y necesidades de los usuarios.
            Pero no debemos olvidarnos (como mínimo) que una ver que tenemos una beta de producto este requiere ser contratado con los potenciales usuarios con el fin de conocer cuáles son sus experiencias en un primer contacto con el producto  para reducir la curva de aprendizaje al máximo.

            Esto es lo que dice la teoría, veamos que ocurre en la práctica.

            El diseño entrado en el usuario es un mantra  de la profesión, en el mejor de los casos se logra incluir a “algo” parecido a un usuario,  pero en la mayoría de las ocasiones es una coletilla que aparece en los documentos de offering.
            Esto ocurre porque el “diseño” del producto no solo lo ejercen los diseñadores (aquí caben todos, AI, UX, Uxd,…) sino que además está el jefe de proyecto preocupado de los procesos, el cliente  con su idiosincrasia propia y el director preocupado de su visión.

            ¿A que nos lleva esto?

            A un conflicto de intereses entre el contexto del producto, el proceso de producción y la visión de la empresa haciendo que la parte más débil en la cadena de decisiones sea la que más se resiente, por muy poco sentido que tenga, ya que una visión que no esta orientada a satisfacer la demanda del mercado, unida a unos procesos optimizados al máximo con el fin de abaratar costes de donde no se puede y con un contexto de producción simplista deberían tener todas las papeletas para fracasar. Pero ahí esta el mundo real ™.

            MUSiC Methods

            Thursday, 19 de February de 2009

              Comillas 2.0 The MUSiC methods were specifically developed by the European MUSiC (Metrics  for Usability Standards in Computing) project to provide valid and reliable means of specifying and measuring usability, while also giving diagnostic feedback which enables the design to be modified to improve usability. MUSiC includes tools and techniques for measuring user performance and satisfaction.Comillas 2.0

              Tomado de Measuring usability as quality of use, Software Quality Journal, 4, 115-150 (1995)

              ¿Así que  existe una especificación que permite cuantificar la usabilidad de las aplicaciones, y que además está documentada?
              El responsable es Nigel Bevan,  que además que resulta que los más viejos del lugar hasta puede que le vieran en su visita a España.
              El proyecto MUSiC  es un análisis de contexto de uso  que emplea métricas de usabilidad (User Performance Measurement Method y SUMI)

              bullet.gif Referencias:

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