Liste des publications en ordre chronologique :

## Bouc émissaire (2021-01-16)

Déplier pour lire le contenu de l’article

> And so naturally, we apply our view of the world, our values. If you view your users with contempt, then the reason behind why people don’t like complicated products is because they are stupid and lazy. If, on the other hand, you respect your users, you might view things differently.

> Disrespectful Design-Users aren’t stupid or lazy (cache)

Deux articles qui invitent à revisiter notre rapport aux utilisateur·ice·s et à la responsabilité que l’on peut avoir dans leurs désarrois face à nos productions. Il est assez aisé d’éprouver de l’empathie pour ses pairs. En revanche, lorsqu’il s’agit de personnes très différentes, il est beaucoup plus difficile de se mettre à leurs places. Et c’est là où réside l’enjeu d’une approche qui a l’intention d’être inclusive.

> This shouldn’t be about shaming individual habits, it’s counter-productive to data shame users. Those of us designing and building these digital products and services should be the ones taking responsibility for ensuring that they’re fit for a more sustainable world.

> Designing Branch: Sustainable Interaction Design Principles (cache)

## Fun (2021-03-09)

Déplier pour lire le contenu de l’article

> And there’s plenty of other backfill features, as we like to call them. The stuff you’re just supposed to do. The things people will ask for.

> But people don’t ask for weird. They don’t ask for different. They even rarely ask for fun. Practical? Yup. Configurable? Definitely. Life is more than just that, though.

> […]

> That’s why its our duty to stand up for weird/different/fun. Give it a seat at the planning table.

> Keep HEY weird (cache)

C’est une des choses qui me titille avec les entretiens utilisateur·ices, les approches LEAN, etc. On obtient des produits plus pertinents, plus rapidement mais qu’en est-il de la partie fun ? C’est déjà très bien d’arriver à un outil fonctionnel mais comment le conjuguer à une « humanité » imparfaite et surprenante ?

Dans cet étau d’efficacité, on passe peut-être à côté de quelque chose d’important. On court après une recherche aussi rapide que celle de Google, un achat aussi 1-click que celui d’Amazon, une interface aussi simple que celle d’Apple mais les fois où j’ai des émotions c’est quand je me connecte au site même-pas-en-HTTPS de la ferme du coin pour commander des œufs et qu’ils me répondent manuellement pour me dire À dimanche !.

## JavaScript-less (2021-03-22)

Déplier pour lire le contenu de l’article

> With a few minor omissions and links, you can create a site that works great in modern browsers with ES6+ and acceptably in browsers without JavaScript. This approach is more sustainable for teams without the resources for extensive QA, and more beneficial to users of nonstandard browsers. […]
> The best way to help your IE11 users is to provide a great experience for your non-JS users and share that experience with them, instead of sending them an untested and buggy experience that also slows the experience of users with modern browsers.

> Dropping Support For IE11 Is Progressive Enhancement (cache)

Je trouve cette approche particulièrement pertinente, un peu difficile avec une SPA sans serveur tout de même. Et encore, il y aurait des choses à expérimenter : on peut potentiellement aller très loin en CSS uniquement avec des `:checked` par exemple. À voir à quel point est-ce que ça endommage l’accessibilité par ailleurs… les défis techniques hypothétiques sont parfois de fausses bonnes idées pour des usages qui sont eux bien réels.

Les tests utilisateur·ices sont une source intarissable de découvertes impensables. Qu’il faut pourtant panser.

## Produit (2021-04-30)

Déplier pour lire le contenu de l’article

> This was surprising because it seems so clearly against our own interest. In almost every case, companies fail because they build the wrong thing. Unless your customers are themselves engineers, I’m the wrong person to help with that. You want someone comfortable at the periphery of your system, who wants to learn about the competitive landscape, who wants to talk to customers. You want a product engineer.

> trapped in the technologist factory (cache)

C’est un long cheminement personnel pour arriver à cette conclusion. Le mien a duré de très longues années et d’une certaine manière je continue de l’arpenter. Se rappeler quotidiennement que le produit que je développe n’est pas égoïstement pour moi — ou ma propre acquisition de connaissances — mais au service d’autres personnes. Cette démarche requiert un certain niveau de prise de conscience puis d’empathie pour espérer faire un produit utilisable et utilisé.

Et pendant ce temps là :

> I choose requests from this list based on my current mood and what I would like to implement next. There is no secret sauce behind it. It’s all about building what people want.

> The story of a unicorn solo founder making $500,000 ARR (cache)

## Client (2021-11-06)

Déplier pour lire le contenu de l’article

> The central cause of the failure was another anti-pattern, CEO as Customer. And it turns out that a company that can’t invest in the quality of its mainline product, won’t invest in the quality of its replacement, either. That’s a management anti-pattern, and starting over with new people and a blank piece of paper doesn’t change management. Only management can change management.

> The Inner Osborne Effect (cache)

CEO comme client < Comité directeur comme client < Équipe de développement comme cliente < Équipe produit comme cliente < Interviewé·es comme client·es.

Étonnamment, entre le biais de sélection et la transformation des personnes recrutées, « Client comme client » est très difficile à atteindre.

À moins d’être son propre client.