Publications similaires
19 chose à ne pas dire à un UX researcher
📌 ARTICLE sympa, sur un ton décalé des 19 choses à ne pas dire à un UX Researcher :
1/ « Nous n’avons pas besoin d’un rapport »
2/ « Cette méthode est trop coûteuse et trop longue »
3/ « Utilisons une salle à miroirs sans tain »
4/ « Avez-vous demandé à l’utilisateur ce qu’il aime dans le produit ? »
5/ Faisons des NPS (net promotor score)
6/ « Tout le monde peut lire un script et prendre des notes »
7/ « Je vous montrerai mon design quand il sera terminé »
8/ « Utilisons nos propres employés comme participants »
9/ « On peut juste faire une enquête »
10/ « Organisons plutôt un focus group »
11/ « Avez-vous demandé à l’utilisateur s’il achèterait ce produit / service »
12/ « Les gens ne scroll pas autant, les résultats de recherche ne peuvent pas aider. Mettons le CTA ailleurs ».
13/ « Lire les protocoles de recherche aux participants mot pour mot »
14/ « J’ai pensé que nous pourrions nous rencontrer tous ensemble » – L’utilisateur veut passer l’interview avec ses collègues / amis
15/ « Faisons juste quelques tests d’utilisabilité, pas besoin de recherche »
16/ « Nous ne pouvons rien obtenir de valable en parlant à un si petit nombre de personnes ».
17/ « Il suffira de le tester auprès des utilisateurs à la fin du projet »
18/ « Nous n’avons pas besoin d’un paneliste pour trouver des utilisateurs »
19/ « Nous sommes une startup, nous n’avons pas encore besoin de recherche sur les UX… »
(pour voir l’ensemble des conseils, sur ce qu’il convient dire à la place, je vous invite à lire l’article 😉 )
#UXResearch #cmondary
Que signifie être vraiment « Agile » en tant que designer ?
📌 ARTICLE très intéressant sur l’agilité et l’adaptation du designer au manifeste Agile.
Fonction de la maturité du client mais également des enjeux de communications, les choses ne sont pas toujours simples. Je partage tout de même assez les conseils de l’auteur !
1/ Etablir un vocabulaire commun entre les différentes parties prenantes (communiquer efficacement niveau 1 😉 )
2/ Comprendre puis concevoir en gardant à l’esprit les enjeux business et les contraintes techniques
3/ Concevoir et maintenir des modules réutilisables (voir maintenir un design system)
4/ Délivrer à court terme, mais conserver toujours une vision à long terme
5/ Prendre des décisions stratégiques au bon moment et épauler le ProductOwner (communiquer efficacement niveau 2 😉 )
6/ Éviter d’être (trop) un puriste quant au process
7/ Soyez un coéquipier efficace, mais aussi et surtout un bon négociateur (communiquer efficacement niveau 3 😉 )
#tips #cmondary