Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Managing stakeholders personas kano analysis

638 visualizaciones

Publicado el

We describe how to combine the kano analysis and writing user personas in the context of managing requirements to build a coalition of stakeholders.

Publicado en: Tecnología
  • Sé el primero en comentar

Managing stakeholders personas kano analysis

  1. 1. Yves ZiebaStrategy and Innovation expertManaging Stakeholders
  2. 2. Contact details Yves Zieba GREENSPIRE ADVISORY +41 79 561 1054
  3. 3. Personas are a great way to manage your requirement gathering Personas, used in combination with Kano analysis is a great way to manage stakeholders requirements to: maximise customer satisfaction improve ergonomics in product design process focus on the end user experience
  4. 4. Do’s and Dont’s – User Personas for great User Experience DO Discover personas as a byproduct of your requirements investigation process. Write specific personas i.e, for a single person. The "generic user" will bend and stretch to meet the moment, but your true goal should be to develop software which bends and stretches. Your personas should "wiggle" under the pressure of development. Identify the personas goals and in turn see what your system needs to do, and not do. Have a finite number of personas, your goal is to narrow down the people that you are designing the system for. A primary persona is someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona. DON’T Sometimes you want to identify negative personas, people that you are not designing for. Have more than three primary personas, it means that your scope is likely too large. Have a finite number of personas, your goal is to narrow down the people that you are designing the system for.
  5. 5. Kano Analysis A way to position requirements on a 2 dimensional axis. An excellent prioritisation process for product feature development, or service value proposition, Where customer satisfaction is weighted heavily Where needs are categorised into 4 possible groups: - «Must be» is expected by the customer - «Delighter» is exceeding customer satisfaction. Delighters do not last - «Indifferent» Whether or not they are included, makes no difference - «Reverse» Some users will like, others won’t. - Performance caracteristics, wow characteristics will make the difference
  6. 6. Quality Characteristics: Wow effect does not last From «wow» to «basic», the feature / characteristic lifecycle. Competition does not sleep Understanding competition dynamics is crucial.
  7. 7. More information and recommended Tutos YouTube Video showing a Prezi presentation on product design (English) YouTube Video with a car example.
  8. 8. What else is useful Used in combination with other models, this becomes an even more powerful tool to serve the purpose of managing stakeholders well. Examples include: Business Value Definition Behaviour Driven Development Test Driven Development Serious Gaming / Gamification Lightweight documentation Competition Dynamics (User) Story Telling For more information on any of those, please get in touch by email