LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
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
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.
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
Quality Characteristics: Wow effect does not last From «wow» to «basic», the feature / characteristic lifecycle. Competition does not sleep Understanding competition dynamics is crucial.
More information and recommended Tutos YouTube Video showing a Prezi presentation on product design (English) YouTube Video with a car example.
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 email@example.com