Zenith

La plupart des gestionnaires de tâches affichent tout ce que vous n'avez pas fait. Ouvrez-en un lors d'une mauvaise semaine et la première chose qu'il communique est l'échec : un mur d'éléments en retard sans aucune idée de ce qui progresse réellement.

Zenith part du postulat inverse. Le tableau de bord s'ouvre sur quatre compteurs (total, terminées, en cours, en retard), de sorte que l'état de la semaine se lit d'un coup d'œil plutôt qu'en défilant, et « terminées » a le même poids visuel que « en retard » au lieu d'être masqué.

Chaque carte de tâche comporte une barre de progression segmentée et un compteur du type 06/14. Les segments comptent : une barre continue à 43 % est un chiffre à interpréter, tandis que quatre blocs pleins sur neuf forment une forme que l'on reconnaît avant même de lire.

La priorité est un menu déroulant libellé, pas un simple code couleur. La couleur la renforce, mais le mot « Haute » porte le sens : un point rouge est invisible pour un daltonien rouge-vert et ambigu pour tout le monde.

L'écran de détail de tâche prolonge la même idée. Priorité, statut et date d'échéance sont empilés en lignes libellées, et les sous-tâches forment une checklist avec un compteur visible 2/4, de sorte que la prochaine action est toujours concrète plutôt qu'une obligation vague.

Les thèmes clair et sombre sont tous deux conçus ici, pas l'un conçu et l'autre inversé. Chaque écran existe dans les deux, ce qui est le seul moyen de repérer les endroits où une palette inversée casse : le remplissage de progression pâle qui disparaît sur blanc, la surface de carte qui ne se distingue plus du fond lorsque les deux sont sombres.

Les deux thèmes lisent un même ensemble de tokens couleur, typographie et espacement, si bien qu'un changement dans l'échelle s'applique aux deux simultanément. C'est la différence entre livrer un mode sombre et le maintenir.

Cela a aussi rendu le décompte des écrans honnête. Concevoir recherche, notifications, calendrier, profil et création de tâche deux fois n'est viable que si les composants sont partagés, ce qui s'avère une limite utile au nombre de composants sur mesure qu'un design peut se permettre.

Au-delà des trois écrans principaux, le concept couvre la création d'une tâche et d'un projet, la vue calendrier, la recherche dans les deux thèmes, les notifications et les paramètres de profil. Ce sont les écrans qu'une démo saute et dans lesquels un vrai utilisateur passe son temps.

Les concevoir est aussi ce qui teste le système. Une bibliothèque de composants semble complète jusqu'à ce qu'on essaie de mettre en page un écran de paramètres, ce qui est généralement là où les lacunes d'un jeu de tokens se révèlent.

Un ensemble complet d'écrans en deux thèmes (tableau de bord, liste de tâches, détail de tâche, création de tâche et de projet, calendrier, recherche, notifications et paramètres), construit sur un jeu de tokens partagé plutôt qu'assemblé écran par écran.

En tant que concept, il n'y a pas de données d'utilisation derrière, et cette page ne prétend pas le contraire. Ce qu'il démontre est la partie transférable au travail client : concevoir les deux thèmes en même temps, garder les statuts lisibles sans dépendre de la couleur, et couvrir les écrans qui ne comptent que lorsque le produit est réellement utilisé.