Un design qui tient en production, pas seulement dans un prototype.

Le design UX et d'interface couvre les écrans avec lesquels quelqu'un interagit. Le service design couvre tout le parcours autour de ces écrans, y compris ce qui se passe hors écran : une transmission humaine, un e-mail de confirmation, un processus d'entrepôt, que le client vit comme une seule chose continue même si cela traverse plusieurs systèmes et équipes. Nous faisons les deux car une belle interface échoue quand même si le processus derrière est cassé.

Les deux. La même discipline de recherche et de cartographie de parcours s'applique, que l'utilisateur soit un client externe ou une personne de votre équipe utilisant un outil pour faire son travail. Les outils internes sont souvent là où le mauvais design coûte le plus de temps perdu, alors qu'ils reçoivent le moins d'attention en matière de design.

En construisant des systèmes de design d'interface (des composants définis une fois et réutilisés de façon cohérente), et en validant les designs avec des tests de prototypes avant qu'une seule ligne de code de production ne soit écrite, afin que les problèmes soient détectés dans un prototype cliquable plutôt qu'après que l'ingénierie l'a déjà construit. Et comme l'IT fait partie de la même entreprise, il n'y a pas de rupture entre le fichier de design et la construction.

À la fois qualitative et quantitative : entretiens et sessions d'usabilité avec de vrais utilisateurs, ainsi que des données comportementales sur la façon dont les gens utilisent réellement le produit actuel, plutôt que des hypothèses sur la façon dont ils devraient l'utiliser. L'étape un consiste explicitement en recherche et découverte avant que tout écran ne soit conçu.

Oui. Un système de design existant est un point de départ, pas quelque chose que nous remplaçons par défaut ; nous l'étendons et l'affinons selon les besoins plutôt que de le remplacer, sauf si l'audit montre qu'il freine réellement le produit.

De vrais utilisateurs. Les tests d'usabilité sont une étape définie du processus, pas un extra optionnel : les designs sont validés contre un comportement réel avant que le code de production ne soit écrit, car l'opinion interne sur ce qui est intuitif est un mauvais substitut à observer quelqu'un essayer réellement de l'utiliser.