Agoda PBS Config

Étape 2. Recherche et Idéation

2.1 Opportunité de S'aligner avec un Nouveau Système de Conception

Compte tenu du délai limité pour ce projet, j'ai collaboré étroitement avec le propriétaire du produit pour définir les exigences du nouveau flux d'approbation par le biais de synchronisations régulières de conception. Un audit du produit existant a révélé que le portail MVP avait été construit sans l'apport d'un concepteur et reposait sur Bootstrap pour son interface utilisateur, ce qui a entraîné un produit fonctionnel mais dépassé.

J'ai proposé de tirer parti du système de conception existant d'Agoda, le Système de Conception d'Agoda (SCA), pour résoudre ce problème. L'utilisation du SCA réduirait le temps de production en utilisant sa vaste bibliothèque de composants pré-construits. De plus, l'équipe de configuration PBS recevrait le soutien de l'équipe du SCA pendant la phase d'adoption. Cette adoption rationaliserait le processus de conception et alignerait le produit avec d'autres applications Agoda, garantissant une expérience utilisateur cohérente et moderne.

Bien que l'équipe d'ingénierie ait été préoccupée par une refonte majeure, les avantages de l'adoption du SCA l'emportaient de loin sur les efforts nécessaires.

2.2 Première Itération

La première étape de la conception a été de rafraîchir la liste des tableaux existants de toutes les configurations à l'aide du SCA.

En travaillant sur le tableau, j'ai cherché à comprendre les informations les plus importantes pour un utilisateur administrateur lorsqu'il décide d'approuver ou de rejeter une demande de configuration.

L'utilisateur principal de ce nouveau portail a fourni des informations précieuses sur les informations dont son équipe avait besoin pour prendre des décisions.

Informations nécessaires du point de vue d'un administrateur :

• Informations sur la Configuration elle-même :

  • ID de la Configuration

  • Nom de la Configuration

  • Fréquence d'Exécution de la Configuration

  • Nombre de Magasins

  • Coût de Chaque Configuration

  • Statut d'Approbation

  • Type d'Affectation (indiquant quelle équipe demande ce type de configuration)

  • Relation de la Configuration (indiquant s'il s'agit d'une configuration parent ou enfant)

• Informations sur les Paramètres des Magasins Réalisés :

  • Délai de Traitement

  • Durée des Séjours

  • Occupants

  • Segment de Domaine

  • Devise

  • Langue

  • Origine (indiquant s'il s'agit d'une réservation nationale ou internationale)

• Informations sur le Demandeur :

  • Qui a Créé la Configuration

  • Quand la Configuration a été Créée

Compte tenu des informations détaillées sur les configurations, nous avons conçu une interface intuitive où les utilisateurs peuvent facilement approfondir les détails sans être submergés par des détails initiaux excessifs.

2.3 Changements Additionnels

Grâce à des synchronisations supplémentaires avec le propriétaire du produit, nous avons décidé de regrouper toutes les actions sous un menu hamburger pour rationaliser l'interface utilisateur.

2.4 Dernière Itération

Dans la dernière itération, nous avons abordé des cas particuliers pour divers scénarios :

• Gestion des approbations des demandes de configuration

• Gestion des refus des demandes de configuration

• Gestion des erreurs système en arrière-plan lors des demandes de configuration

• Gestion du filtrage

Cette appro ore_visage_avec_sourire he exhaustive a permis de garantir que la conception était robuste et conviviale, en tenant compte de divers problèmes potentiels.