Choisir la franchise comme méthode de communication
On enfonce les portes ouvertes en disant qu’il est toujours plus bénéfique de privilégier la transparence dans nos relations afin de rentrer dans une cycle de confiance mutuelle ; pourtant, il est toujours important de la rappeler tant il est difficile de le préserver au quotidien.
Pour illustrer cette évidence deux extraits d’articles, le premier parle de l’intérêt de laisser de la place pour des impressions dites « négatives » sur des propositions ou des services (afin de les améliorer). Une manière de laisser les gens dirent ce qu’ils pensent au fond de leur être intérieur : The power of negative reviews.
The first thing brands need to remember is that there is always truth in complaints and, as such, negative feedback can actually be used to shape and improve a business model.
A willingness to address complaints shows that a business has pride and faith in its products and services, and cares about their customers’ experiences, not just their custom. This honesty and humility is instinctively picked up on by those looking to engage through social platforms and are paramount to creating a positive emotional connection.
L’auteur résume cette place laissée à la libre expression à de l’humanité dans les rapports entre un service et ses utilisateurs.
Simply by reacting to negative feedback, brands provide closure for the complainant; ultimately all consumers want is to be heard and when they are, they are more likely to remain loyal. In fact, a study from Maritz found that 83 per cent of complainants that received a response either liked or loved the fact that the company responded.
Dans l’article How We Operate – The Potential Client, Noah Stokes montre la manière dont l’agence Bold établit sa relation avec un client.
On remarque que leur démarche essaye de creuser au maximum la connaissance qu’ils peuvent avoir de leur interlocuteur. A chaque appel téléphonique, ils essayent de poser le maximum de questions permettant de mieux cerner le projet.
When we initiate a phone call, it’s almost like a first date. We get a chance to talk about what we do, our methodologies, philosophies and practices and the client gets a chance to talk more about their project and where they see Bold fitting in it. We always have blank TextEdit open during the call and write down as much as we can. Client services is as much about the client as it is about the work. We take notes about everything from personal quips about life to subtle suggestions about technologies. You would be surprised at how much you can learn about a client just by listening.
Finalement, ce qui devrait guider nos relations dans la vie et dans le travail, c’est l’humain. Sans cette humanité, c’est d’un coup beaucoup moins passionnant.
La problématique de la conception responsive
J’essaye de le montrer depuis quelques temps déjà, mais la logique de conception responsive implique un changement de la méthodologie de conception et de réalisation. Rudy Rigot évoque ce sujet dans un article très complet dans lequel je vais piocher quelques paragraphes.
Basically, you had the infamous sequence: specifications – conception – design – front-end dev – back-end dev, and all the small pieces before, after, and in-between. Each of these areas didn’t need to know that much about each other. For example the front-end developer could work on the project weeks after the conception.
De manière classique, vous procédez à la séquence suivante :
- spécification
- conception
- habillage
- intégration graphique
- développement fonctionnel
Chaque phase fonctionne de manière quasi-indépendante et n’a pas besoin de connaître comment fonctionne l’autre. Un système de division du travail dans lequel chaque métier est découplé (un chef de projet réalise le liant).
Responsive design imposes tight technical constraints on the conception, which completely turn this model on its head. You can’t produce one fixed-width wireframe like before, and expect all of the website’s interaction to be conceived from this. And you can’t expect a functional designer to produce an output that is technically relevant, if he doesn’t have a solid technical background allowing him or her to respect the flow of content into different responsive layouts, and isn’t working closely with someone who does.
La conception responsive impose des contraintes techniques particulières, qui remettent en cause le modèle précédent. Il n’est plus possible de partir d’un écran présentant une largeur de colonne fixe et, de plus, espérer concevoir les interactions sur celui-ci. Ce gabarit sera difficile à interpréter une fois arrivé au stade du développement front-end.
So, should you ask your front-end developer to make wireframes? Or wait, should you expect HTML/CSS pages right away, created by your graphic designer? Headache!
A ce stade, plusieurs questions peuvent vous venir à l’esprit, il pourrait être pertinent de donner la réalisation des gabarits ou encore de demander à votre graphiste de coder des pré-gabarits. Que choisir ?
One thing is for sure: in a team-driven project, the separation of roles and expertise is not as clear as it used to be, and a simple « let’s do it responsive » mantra is not good enough — we need to redefine the order in which we’re used to doing things.
Plutôt que de trancher en espérant une monté en compétence illusoire des membres de vos équipes, il conviendrait, peut-être, de passer à une vision équipe. Equipe, dans laquelle les compétences, les rôles, ou encore les expertises ne sont pas strictement déterminées, il suffit pas de dire « faites moi un site responsive » pour avoir un résultat conforme aux attentes. Il est préférable de redéfinir les priorités et de passer par un peu plus d’autonomie.
On retrouve donc dans cet article un point de vue inhérent à la conception web : la division du travail est contre productive dès qu’on veut atteindre des objectifs d’interopérabilité, de qualité, de performance et d’accessibilité.
Note : l’explication de cette réalité s’explique par le niveau de complexité à maîtriser ; la division du travail peut, effectivement, se justifier dans un cadre ou la complexité est maîtrisée ou réduite.
Lire : Responsive web design: a project-management perspective.
Donner de l’autonomie n’exempte pas de méthode et de contrôle
L’article de Bertrand Duperrin, qui se nomme L’entreprise sans manager n’est pas l’entreprise sans management, répond à la question liée à la problématique de la conception collaborative : mais qui c’est qui dirige ?
Lorsque vous présentez le principe de la conception collaborative sans relation hiérarchique entre les personnes ; les interlocuteurs sont tentés mais bloqués par le principe de suppression du chef.
Car en effet le problème de la conception collaborative c’est qu’elle demande un changement de système (hiérarchique). On sait, à ce propos, qu’il est très difficile de convaincre les gens d’en changer (de système) étant donnée que tous leurs repères sont calqués sur l’ancien système.
Ainsi, même en voyant les grand avantages d’un système plus équilibré, il leur vient à l’esprit, premièrement, une sorte de corps sans tête (sans chef) qui ne saurait plus où aller et, deuxièmement, une probable perte de leur investissement dans l’ancien système disparaître (leur position hiérarchique).
C’est pourquoi, il sera plus facile de convaincre des personnes n’ayant aucune responsabilité et plus difficile de convaincre des personnes qui risquent de perdre leur avantage leur pouvoir de chef, mais aussi leur salaire et tout ce qui va avec.
Pourtant, les entreprises sans manager existent, et les les entreprises sans manager fonctionnent. Mais pourquoi donc ? Parce qu’on supprime l’égo, le pouvoir, la soumission. Les employés peuvent parler plus librement, parler plus librement des problèmes de management justement.
Dans de tels systèmes, très responsabilisants pour les collaborateurs, le management n’a pas disparu mais a été distribué. Ce qui amène à une situation paradoxale : il est infiniment plus présent que dans une organisation où il est incarné par quelques uns.
Mais allons plus loin, pourquoi est-ce si nécessaire de passer à ce modèle ?
Les modèles savoirs/services font de l’entreprise une machine à générer et traiter les aléas, et l’aléa n’est plus la conséquence d’une défaillance du système mais sa raison d’être. Le collaborateur doit prendre des décisions dans un délais limité, le problème doit être traité au plus proche de l’endroit où il survient (et au plus proche du client) et le client devient de plus en plus partie prenante de l’activité de production, introduisant une autre variable et une source d’exigence externe à l’entreprise dans ses propres processus.
N’êtes vous pas dans cette situation d’urgence ? Si, si je le sais, puisque c’est le modèle économique. Et qu’elle est le problème ? La centralisation.
Dans un tel contexte le manager trônant au sommet d’une structure pyramidale devient le goulot d’étranglement du système qu’il ne fluidifie plus mais, au contraire, ralentit.
La solution : éviter les managers, chefs de projets tout ces postes de contrainte et de centralisation. Privilégier, l’autonomie mais surtout, n’oubliez pas pour autant le management (qui passe par des collaborateurs compétents).
L’intégrateur est un lettré du web
Hier, je suis allé à Compiègne pour une petite intervention. Proche de la conclusion, Serge Bouchardon s’est exprimé pour prononcer une remarque ; il a dit : pour moi, Bertrand, tu es un lettré du web.
Alors, ce matin, j’ai cherché ce que pouvait bien être un lettré et je suis tombé sur cette définition.
Ils lisent des textes, les rassemblent, les éditent, les commentent, les transmettent aux générations futures, produisent à leur tour d’autres textes : ce sont les lettrés, apparus parmi nous voici déjà quelques millénaires. Voués à l’écrit, ils forment le socle d’une civilisation, en garantissent la continuité, mais participent aussi à sa contestation. Le plus souvent invisibles ou méconnus, ils composent une communauté secrète, reliée à travers les temps et les lieux par des rites partagés, des habitudes analogues, des affinités mystérieuses.
La vitesse de chargement plus importante que l’esthétique
Vous les intégrateurs, les développeurs, vous le savez, la mise en forme, ça compte, mais quand on doit visiter plusieurs fois une page par jour (lors de vos tests), ce qui prend de l’importance, c’est le temps de chargement.
Une étude sur la perception du mobile par les utilisateurs, donne quelques résultats intéressants.
When asked “What is the most common problem you’ve encountered accessing websites or applications on your mobile phone?”, respondants answered “Slow to load” (38%), “Crashed/froze received an error” (18%), “Formatting made it difficult to read and use” (15%).
This tells us that speed is more important than aesthetics. So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.
Quand on demande aux utilisateurs : quel est le plus problème le plus agaçant lorsque vous accédez à un website ou une application mobile ? Les réponses concernent « la rapidité de chargement » (38%), « crash ou erreurs systèmes » (18%), « la présentation rend le contenu difficile à lire ou à utiliser » (15%).
Ainsi, la rapidité de chargement est plus importante que l’esthétique. Peut-être que parfois le temps passé à optimiser les media queries, la zone d’affichage, le défilement, la longueur de ligne serait plus bénéfique s’il était consacré à réduire le nombre de requêtes HTTP ou optimiser le chargement perçu.
Mettre le graphisme comme élément central d’une conception, confondre design et l’esthétisme, ne permettra pas de répondre aux attentes premières des utilisateurs.
Lire What Users Want from Mobile, and what we can re-learn from them.