Je suis affecté à un énorme projet en tant que stagiaire en conception ux, actuellement ce projet n'a aucune documentation. Et apparemment, n'importe qui dans le projet ne connaît pas 100% de la logique et du domaine du système, à l'exception des personnes âgées. mon aîné veut que j'apprenne toutes les choses dans un délai d'une semaine. existe-t-il une méthode rapide pour ce faire?
D'abord, vous devez rester aussi naïf que possible pendant que vous vous asseyez avec le système tel qu'il est et l'exercez sans le recours à la documentation.
Exercez toutes ses fonctions, dans la mesure où vous pouvez comprendre ce qu'elles sont. Faites de l'exercice de façon systématique et prenez des notes copieuses sur les difficultés que vous rencontrez, quelles qu'elles soient ou à quel point elles sont faciles à surmonter. Que cherchiez-vous, qu'avez-vous trouvé, comment vous attendiez-vous à ce que cela fonctionne et pourquoi, comment cela a-t-il réellement fonctionné et à quel point a-t-il été difficile de rembobiner vos erreurs et de revenir à l'endroit où vous vous trouviez avant de retirer par inadvertance le support tenant le toit.
Vous essayez essentiellement d'écrire l'histoire d'un client entièrement naïf mais intelligent qui pense que la façon d'utiliser un logiciel devrait être découvrable sans documentation et sans rien casser, et ce qui s'est passé lorsqu'il a rencontré le logiciel.
Une fois que vous avez fait cela, récupérez la documentation et recommencez, mais cette fois en utilisant la documentation. Quel rôle joue la documentation? Essaie-t-il de compenser des choses que le logiciel lui-même devrait rendre évidentes mais pas? S'agit-il essentiellement d'un manuel de référence, d'un tutoriel, d'un document marketing ou autre chose? Est-ce inégal et inégal, montrant que trop peu de temps a été accordé aux auteurs? Est-ce déroutant? Est-ce précis ? Est-il complet ?
Une fois cela fait, vous vous serez fait un client virtuel et pourrez travailler de ce point de vue. Mais continuez à rester naïf si vous le pouvez, car acquérir de l'expertise est une voie à sens unique. Une fois que vous êtes un expert, vous oublierez comment cela devait être un novice et vous ne pourrez plus trouver les problèmes que les novices trouvent.
Votre stratégie globale doit être d'être curieux, de poser beaucoup de questions aux différents intervenants de l'entreprise et de savoir comment ils travaillent avec le produit. découvrez comment ces personnes contribuent au produit. et leur travail quotidien avec le produit.
En ce qui concerne le produit lui-même, mettez-vous dans la peau d'un utilisateur et utilisez le ou les produits à fond. Faites-le en tant qu'utilisateur complètement nouveau, ainsi qu'en tant qu'utilisateur expérimenté. Cela vous aidera à trouver des flux pour chaque produit. lors de son utilisation, faites autant d'erreurs que possible pour identifier la façon dont le produit gère les erreurs et les cas Edge. utilisez également toutes les fonctionnalités dans diverses combinaisons. documenter toutes ces fonctionnalités.
Pendant que vous faites cela, beaucoup de questions et d'améliorations vous viendront à l'esprit. les exprimer et les documenter.
J'ai tendance à être d'accord avec Ameen, les parties prenantes ont les informations, même si aucune partie prenante n'a tout. Les 2 parties prenantes les plus importantes pour vous sont le Product Owner et le Business Analyst. S'il s'agit d'une solution existante, vous pouvez tricher et demander à l'UX qui l'a conçue. Si c'est une solution qui vient juste d'être conçue, un bon UX parle à chaque département et partie prenante et agrège et consolide les informations. Je vous assure que la plupart des parties prenantes auront des idées différentes sur ce que la solution est conçue et comment elle fonctionne - en fait, c'est l'une des raisons pour lesquelles vous avez besoin d'une bonne UX, pour trouver et joindre tous les points. Une fois que vous êtes satisfait de ce qu'on vous a dit, le et alors seulement, regardez la conception de la solution et voyez si elle répond à vos attentes nouvellement acquises
Il semble que le système soit suffisamment grand pour que vous ne puissiez pas en savoir plus sur tout. Je vous suggère de prioriser. Commencez par les tâches principales de l'utilisateur. Quelle est la principale raison pour laquelle les gens utilisent votre système? Qu'est-ce qui est secondaire? Concentrez-vous sur les fonctionnalités qui prennent en charge ces tâches.
J'espère que vos aînés pourront vous donner cette information. Une autre bonne façon de découvrir comment les gens utilisent le système est de parler avec vos collaborateurs Analytics.
Bonne chance.
Dans votre situation, je ferais ce qui suit:
Ceci est essentiellement basé sur Tester, construire, mesurer, répéter. Si vous voulez toujours en savoir plus, vous pouvez vérifier ce qui suit link vous pouvez également regarder "Sprint-design by GV" cela pourrait vous aider à faire une expérience utilisateur lean rapide et rapide avec votre équipe.