About the methods
And my feeling about too much focus on them
Project team members are often too much focus on the methods. We somehow chose a method before consider every aspects of a project. Doesn’t it sound like choosing the tool before knowing what we want to do? Would you use a Hammer to build a wall?
Users don’t need methods, they need products that meet their needs. And Methods need to fit the project environment.
Too much on method… Less on result
As far as I can remember, I have always been interested in methods. How to optimise the process to improve the result has been one of my favorite question/hobbit/task. Understanding the patterns, catching them in all the activities I was passionate about, and then, try to automatise them.
In fact, I was more focus on finding the perfect Method than practicing to improve myself and take pleasure. Methods versus results craft…
Few years later, when I started my career in Digital, I was really blinded by methods. Agile methods are the best methods to create a digital product, was my new claim! In all my projects, I spent effort and time to master the process in order to get better results. Nevertheless, my work was not as good as I wanted… The value was not there. Why? Because I was aiming the How to do it rather than focusing on the product I was designing. And also, because I was trying to use Scrum method with a three person-team in a very small company where nobody knew what was an agile method, on very low budget projects…
Methods are just tools, not the project core
Nowadays, all the respectful agencies showcase their abilities to handle projects with great and fabulous use cases following last methods from Google or Stanford! All of my network is pushing articles about Design Thinking, Sprint Design, Scrum and SAFe on LinkedIn and Twitter! And so do I! We are all selling the Method. But, let’s be honest for two seconds! I have the feeling that some of us are looking at all those Methods as if they were the project core.
Sprint Design, Lean UX, Agile UX, Scrum… All those methods are great, and I love them very much! They are awesome tools to ease the way of doing great products! The word is coming: TOOL. Some of us are focusing on the method like the Holy Grail. But from my point of view, it somehow blinds us, and in many cases we try to use one method that doesn’t fit the project. We get lost in Method space like Anakin into the Force!
Woolrych*, a usability researcher and consultant, has written an article with his colleagues comparing methods and recipes, called “Ingredients and meals rather than recipes…”
If you don’t have the good ingredients, you will not be able to cook something great even if you have the recipe. And also, the recipe could have a lack of informations, so that if you follow it, you may experience a failure. So Recipe is definitely not a perfect way to success.
“A recipe is nothing without its ingredients, and just as the quality of what is cooked reflects the quality of its ingredients, so too does the quality of usability work reflect the quality of resources as configured and combined. A method, like a recipe, is at best a guide to action for those adopting approaches to usability that are new to them. As with culinary dishes, HCI needs to focus more on what gets cooked, and how it gets cooked, and not just on how recipes suggest that it could be cooked.”
*Woolrych A., Hornbæk, K., Frøkjær, E. & Cockton, G. (2011). “Ingredients and Meals Rather Than Recipes: A Proposal for Research That Does Not Treat Usability Evaluation Methods as Indivisible Wholes“ International Journal of Human-Computer Interaction, 27(10), 940–970. Sources
Methods need to fit the project
Some projects succeed and some others fail thankfully or because of several factors. But, from my experience, lots of projects fail because of using a method without enough knowledge of what will be the business and project requirements, nor the environment.
Let’s take a practical example. Once, I was supposed to design an application for a pharmaceutical company. It was a complex application with hundred of content pages. We were tight in terms of time with lot of screens to design, and tough user journeys to define. Our team chose to work with an adapted version of Scrum. I bet you know what happened, don’t you?
You guessed right! We spent a lot of time and energy to explain the agile process to people who were not digitalized and no expert in technology. They were great engineers and had long experience in working with their own process. They certainly took years to learn those processes and were quite close-minded about trying a new one. This agile method was not obvious for them. They had not been trained. And during the project they were constantly lost, and they continuously tried to adapt themselves to understand all the steps and the why we were doing this way.
Process are not easy to understand, because humans need to understand the benefits, the aim, and their own place. And for a 3 months project, you can imagine that it’s a lot of adaptation required. And furthermore if I tell you that those stakeholders were not impacted by this application! They were the experts and represented the business and the end users.
Each release was a real torment! For them and for our team! If we wanted to junk an unnecessary functionality, it was not possible. Our client objected that the functionality had been developed and paid so it was supposed to be delivered and finally pushed on production… Even when we proved that this one was inefficient for users.
Unadaptive methods could ruin your project
All this situation created some frustration into the project team. One day, we faced a feature asked by the client, a weird search engine that was impossible to do exactly as demanded. We were in a dead end, and one of our best developer told me this: “You know what? If they want this crazy functionality, I don’t care, it is not my own business. I will deliver it, even if this will cost a lot of days and if it doesn’t work correctly. It will be easier to try to program it rather than to explain to the client that it is a nonsense for the user! » And even me, I was disheartened and no more motivated…
Progressively we slipped from a pro-active team with engaged and good members who produced value and great ideas, always keen to solve complex problems, into a delivery operational team that said yes to every goofy requirement. My UX task was more and more difficult, because of the closed mind on the client side, and also because of my lack of motivation, I was not able to explain every detail of the test results. Therefore, the project was a dismal failure on the user’s view, and on our side.
Transformation is not a part of the project
The lessons to learn from this experience are quite clear:
First, Digital transformation is not in your project scope. Teach people how to use the method, how to implement it, should not be one of the project team’s task. Yes, to lead human to a sustainable good change belongs to change management teams and needs to be done with extreme caution by experienced people into all levels of the company. As an operational team, we are producing a product, and not changing the entire organisation. That’s two different jobs!
And second and important one, the method can be sometime straight and not obvious for rookies. And all the project managers should be more attentive to what are the possible issues in project, what are the transformation level of his client, and what are the stakes of the project before choosing any methods. Because it could change the team spirit, creating some frustration, drawing the motivation, and turning your best mate into the worst Gremlin. And what worst possible result for a delivery team for a digital human-centred product?
Think about all the component of your projects
What I like in using methods is that it helps me to structure my work. If I feel anxious, I have something that reassures me and helps me to move forward. But I have learnt the importance of flexibility. Edgar Morin, the French Sociologist, historian, philosopher, and father of complexity, approaches methods as “chemin faisant” that I offer to translate into English as along the way. Please be indulgent toward this extreme and simplified summary because the master piece of Edgar Morin called “La Méthode**” contains 6 books and it is not possible to explain here the subject. It describes its way of thinking named Complexity across several disciplines such as philosophy, biology, sociology, history… Doing something with the ability to change the method itself along the way. For him the method helps to grow up and to build something (the Life, your career path…). But the method remains at the second level, in the shadow. And even if it’s important, it is not the result of the task or action or the object itself. Thus, method is just a helpful guideline. And it is definitely not the aim. To be clear, Method is not something to strictly follow end to end, but it is general guidelines.
Morin also said: The work “La Méthode” comes from the junction, the synthesis between several and multiple existential and intellectual experiences, all distinct but at the same time inseparables from the strain, the primordial root from where these experiences were born. Thus, looking back this image of the banyan, and from this ever-growing tree are growing lots of branches — educative, sociological, anthropological, historical, linguistic, economical, ethical — allow the “Complexity way of thinking” to materialize and flourish.***
In a more basic approach, I would translate these words by the necessity to understand all the components of a project, from the personal and professional experiences, and chose the most pertinent method to reach the goal with the most chance of success. Use the complexity approach to nurture the method itself, and make something better.
In each project, or type of project, the method helps you and needs to be adapted to your client, to the team, to the complexity, to the technical and functional requirements, and moreover to the user/citizen/human you are working for. In other words, clients, users, teams and stakeholders do not have to adapt themselves to the method; the method needs to adapt itself to all of them. Remember the recipes of Woolrych! Maybe the ingredients are more important than the method.
And as UX designers, the aim is always the same: Understand business needs, understand users and define what they want to achieve, where they encounter issues and also to try to solve them through the design. Here, it’s not about methods, it’s about skills, empathy, experience. Method will be a help, not the shinning star to follow.
In closing, as a useful tool, a method needs to be chosen on different criterions (The famous branches of the Morin’s Banyan?). Context, team, goals of projects, clients, transformation level of this client, goals of business, client company size, technology used, problems to solve, and one of the most important, users. If you answer all the questions around these criterions, you might be able to choose the most relevant method to create value in the best manner. And yes, it is difficult to do this, because we do not take enough time before the kick off, because we are all under pressure, and also because our clients need great product in no time. Perhaps it is impossible to do this right now… But let’s remember the state of UX in early 2010 in France. It was really difficult to sell any user interviews or user tests and to convince client about UX utility. However, today our clients are quite keen to engage UX services, and this at a high level in the value chain. I guess it would take time, but in few years, we will have this time window to chose the most relevant method that suits the project. Once in agile, and the next one in a new method (that we don’t know yet).
I see method such as a specific tool to do something special. Therefore, to raise a wall you will not use a hammer, right? And before choosing your tool, you will try to know what needs to be done. Isn’t it the same in choosing method for your project?
**La méthode contains 6 books that you can find on Amazon here.
***This texte has been translated by me when I was writing this article. Here is the source: [La « Méthode » provient de la jonction, la synthèse entre diverses et multiples expériences existentielles et intellectuelles à la fois, toutes distinctes mais néanmoins inséparables de la souche, de la racine primordiale en quelques sorte, d’où elles sont nées. Ainsi, retournant à cette image du banian, de cet arbre en perpétuelle croissance et développement sont issues de nombreuses ramifications — éducatives, sociologiques, anthropologiques, historiques, linguistiques, psychologiques, philosophiques, politiques, économiques, éthiques — permettant à ce que j’appelle la « pensée complexe », précisément, de se concrétiser et de s’épanouir.]
Originally published at medium.com on March 11, 2019.
