User Experience Design in an Industrial context
A (fulfilling) dive into Groupe Renault Manufacturing world.
Prologue
Being a car enthusiast since the age of 14 (or something), I have read a lot about cars, new almost every upcoming model from almost every car brand in the world.
Naturally I thought I new roughly how cars were built.
Or did I…
Building a 1.5 tons of steel, plastic, fabric, screens object, which has to drive humans around at a top speed of 130 kph, safely, comfortably, for a minimum of 10 years and 200,000 km is, you guessed it, quite complex.
One of the most basic car Groupe Renault has in its wide lineup, the Dacia Sandero (old generation, AND I don’t count the Twizzy, calm down.), is made of 25,000 parts at least, by thousands of skilful men and women, in 8 hours, in Pitesti plant, Romania.
And they make 400 a day. And not a single car is the same, since they are tailored to clients request.
You get the point : little I knew about the clockwork organisation required for making 3.9 millions of cars a year in 35 plants across the world.
Discover
“Out of the confort zone”
After a few months at Renault, I had the opportunity to be onboarded on a quite promising project : Digital Work Station (DWS).
Skipping the organisation details (it would take hours for you to understand the organisation in such a big, international group like Renault), we started with a core team of business and IT specialists, for the “framing” of the project, to be later joined by our development specialists based in Dacia plant offices in Pitesti, Romania.
The aim of the project was to bring digital tools at the heart of the manufacturing : on the assembly line.
While putting operators at the heart of the project, we would try to make their job easier and more efficient, and thus improving on cars quality and productivity.
I started my UX journey by a progressive dive into the theory of manufacturing, the “Alliance Production Way”, the Bible for anyone working in manufacturing at Renault.
One could describe it as a carefully crafted blend of principles written out of the many years of experience in making cars in the Groupe and inspired from the long-time ally Nissan and its Japanese principles of manufacturing.
Only concepts with which I did not know anything about, but which I found to be very inspiring for a lean workflow organisation.
Of course, following my own principle, I found myself quickly dressed up with heavy, yet fancy, security shoes, a pair of earplugs and a Renault-badged jacket.
First dive in the field : Sandouville plant, Le Havre, France.
Industrial world first, international context then, and eventually working with people from a country I honestly did not know anything about, comfort zone boundaries were stretched quite largely.
(About Romania and Romanians, consisting of half of the team, only the cultural details remained a gimmick, for the rest we very quickly worked well together).
“Beyond the theory”
One big challenge on DWS project is the users. You simply cannot put yourself in their shoes and try to project how they work, and how they could use a solution that you plan implementing for them. You need to apply a thorough user experience methodology if you want to know their mindset, their problematics, and work out the best solutions for them. This, of course, means being in contact with them, directly, on the field.
The logo might not be the sexiest, but it conveys the idea.
Hence the commitment of the whole team to stay connected with the realities of the field was and stayed the base of the project.
Once the theory was understood, I could start challenging it on that very field. The first step of my collaboration with the team was to shadow users at different positions in the plant and in the process, and to start roughly map out the real ecosystem, and big areas of improvement through digital solutions.
Plan
“Starting from the experience”
Being true to our commitment, all the discovery phase allowed the team to establish 10 big topics to cover in terms of user problematics.
In Agile words, that would correspond to initiatives (yes the project was agile, following the scrum framework, but that’s not the topic here).
Rather than trying to stick some before-thought ideas of solutions onto user problems, we tried to first focus on the problems experienced by users.
Yes we knew the solution would be digital (seems to be the trend lately), but we kept the idea of solution very blur, on purpose.
Research
“Diving deep down”
Blur was the vision of the solution, but not the research plan.
10 initiatives, 10 workshops in 10 plants.
After a few months on the project, I found myself on a plane for my first real dive in Valladolid and Palencia plants, Spain.
In each of those workshops, we covered one initiative (among the 10 defined, remember).
Two goals for those workshops : first, we aimed for alignement.
As I already said, beyond the theory, we needed to make sure everyone was having the same idea of what it is for real, on a daily basis, to work in a plant assembly shop, as an Operator or an assembly manager. We wanted to make sure no one in the team had Chaplin “Modern times” in mind when we would talk about people working in assembly lines in any of the 35 Renault plants across the world. No offense to Chaplin, but things are slightly different from his vision today.
We then aimed for projection, and started building visions of solutions with users.
Thus, each workshop was split into 3 main phases :
1. Definition of the personas : the idea here was not to describe a “Jean-michel, 48 years old, with a wife, 2 kids and a dog living in a cosy 75 m2 house in the suburbs”, but rather to define the scope of each type of role into and near the assembly line, and figure out their mindset, how they do their job.
2. The “As Is” User Journey : the goal here was to draw out the real daily or weekly routine for each of our personas. Once this was accurately done, we started mapping the “pain points” onto this chronological diagram. In other words, the idea was to identify clearly where were the troubles experienced by our target users, before troubleshooting them.
3. The “To Be” user Journey : time for projection, we started working out the ideal daily or weekly experience for our target users. That stage was when we started putting down ideas of solutions for the initiative covered, which would help us out for the next step.
No need to mention the fact that all this work was done alongside our target users, who could bring us some really dazzling insights.
For instance, I can recall one of the checkman in Palencia plant, Spain, who shared with us his state of mind. For your information, a “checkman” is an operator dedicated to make some quality control operations at the end of a portion of assembly line. It goes without saying that he is a very qualified person, with a high cognitive load. This very checkman was telling us how after his working day, he could almost remember each and every car he controlled in the day (300, more or less).
Hence, for him, it was not only important to digitally have a way to forecast the workload to come by having a view on the cars upcoming, but ALSO to have a view on previously checked cars, even if he stamped them as “OK”.
Of course, we did not think about this beforehand.
Analyse & Conceptualize (and Plan)
“Outside the (sand)box”
Gathering all the precious material we got from the workshops, and in order to bring in the technical and business insights, we started working on Product Visions to implement each initiative.
And productive we were, using once more the field as a great sandbox to test-proof some ideas we prototyped.
Not only we had to be creative in terms of solutions we would bring, but we also had to be creative in the way we would make people test out potential solutions.
“Very demanding users…”
In September of 2019, I spent 3 weeks in the plant as an assembly shop worker (this is part of the onboarding process at Renault, everyone has to spend 3 weeks working as an operator, no matter what you are hired for). Hard yet thrilling experience, it allowed me to really experience the job, and understand its shortcomings (aka “pain points”) and the mindset.
What I want to point out here, is that there is quite a difference between :
1. Designing a digital experience for someone to use once a day, in the chilling quietness of an office, on his 15-inches-retina-MacBook-pro, while comfortably sitting in his 36-positions ergonomic chair
and
2. Designing a digital experience for someone to use 1000 times in a day, in the constant rumbling of a factory building, with gloves, while standing upright, and whose primary task is to make 15 operations under 60 seconds on a partly assembled vehicle, 300 times in a row, for 8 hours a day.
Sure, in the end, both users will most likely wish to perform the action as efficiently as possible, but the difference is that the Operator on the assembly line will have only a second or two to perform this action, and will do it hundreds of times over in a day.
So say you organise accessible actions within menus and submenus with long labels, once again, any 3 steps actions might be acceptable for a user who would have to perform it once a day, but for an already high-loaded Operator who will have to take the action 300 times a day, it turns unbearable.
That’s why we had to constantly and methodically test any concept against users in the field.
“…yet hard to reach”
Yet, users in manufacturing can be hard to reach.
Hence, adding challenge over the challenge, we had small windows of time to perform tests, which we did mostly on site.
Why not using more online-testing tools ?
To keep going with the comparison aforementioned, the context around a user working in a classic office can already make a difference for the final digital experience designed. One will have to take in consideration accessibility, the type of devices mostly used by target users (or go fully responsive, at a cost), target users level of affordance with digital tools, or level of expertise…
For users in the assembly shop, the context makes much more difference : take in consideration the ambient noise level, the low light, moving automated machinery, tooling, dust, grease, the dedicated workspace for each Operator…
So to answer the not-much-online-testing-tool-used question : we had to be on-site to understand that context.
“Beyond the screen”
Not only we had to design the digital product, but also to find the right physical support for it.
A regular screen with a keyboard ? A touch screen ? What size ? What touch technology ? Where to place it at the workstation ? Connection over wire ? Or wifi ?
And for the near managers of each production unit to get the information from Operators ? A smartphone ? A tablet ? How will they carry it ? And what about the battery ? (a shift is 8 hours long with 30 minutes break split into 3, for the battery, no time to die, or to be charged up)
Here is just a glance about the handful of questions the team came up with after all the User Research work on the field.
Before even starting to design the full-fledged version of the digital solution, we had to further test and find the setup solution.
How ? A lab, on site.
This Lab, which would have looked like Ali-baba’s cave for any tech-savvy kid, enabled us to work out the setup solution to be placed in the hands of our users. For that we drove tests, taking in consideration various ergonomic and technical aspects : angles of vision, touch responsiveness, definition, technical hardware to run a webapp…
“A touch of glove”
One thing that comes to my mind and illustrates all this user research process was gloves.
We quickly noticed that everyone having to work in or near the assembly line wore gloves. For security reasons first, because they can come handy whenever one is scraping his hand against a protruding piece of chassis. For quality reasons then, because it prevents people from leaving hand traces all over a brand new car body or interior. This is a standard, but it could have slipped our mind if we did not carefully conduct this user research process on the field.
Upon choosing the best fit in terms of digital setup, we had to make a choice, balancing out the best solution for users, the most reasonable device (the cheapest), and the best technically suitable (not a racehorse but say, something that could handle a modern webapp without burning up).
I remember us gathering all models of gloves used in all 35 Renault plants all over the world in order to test all pre-selected devices, making sure we would have a suitable touch screen for a reasonable price.
No need to say each device went through a thorough test process using a prototype I helped develop.
For the record, we eventually narrowed down the selection to a 15inches industrial device, in portrait mode, with specific recommendations for the placement on the assembly line, and a 5inches industrial smartphone for the near production unit manager to get information.
“Finding the balance”
Our workflow eventually prove to be quite simple : we settled the outputs clearly, and just had to fill them in, to bootstrap the project.
As so, for the MVP (aka “Minimum Viable Product”, aka “The minimum number of features to assemble in order to come out with a consistent response for identified user needs”, aka “The minimum amount of stuff to be developed during the first three months of the project phase”), we needed to come out with 2 distinct outputs :
1. A refined (after several field-tested iterations) and ready-to-dev Product Vision
2. A refined and detailed Story Mapping. Which, in other words, is the list of user needs we would cover for the MVP (Minimum Viable Product, remember).
This exercise looked a lot like carving a piece of wood to make it into a cooking spoon (I did that kind of activity once or twice as a kid). You basically start with a big rough log of wood on which you remove big chunks until you have the desired shape, and you end up polishing the details with finer and finer grain of sand-paper.
Same here : you start with your big rough chunk of Product Vision that covers user needs (and which bears an insane amount of features), then you balance out the technical complexity and the business value, to eventually find the finest compromise between the three.
The concept is yet quite simple : finding the responses to user needs that are the most valuable, yet the cheapest to implement.
Implement…
“Agility”
We eventually found our graal, the so-called MVP (Minimum Viable Product, last call).
We set up our team framework as scrum. I am not going to get into the details here, but basically, we were developing a consistent small batch of features every 2 weeks.
The focus was to keep the mid-term vision sharp, while keeping enough flexibility to adapt the vision according to the feedback we got from our users.
See it like a trip from Paris to Marseille, you have a very detailed idea of your journey thanks to Waze, you know were you’ll eventually land in, but you also know you’ll have to react to contingencies, you did not plan you breaks, nor the fact your 10 year old kid will suddenly feel dizzy at the 568th kilometre near Montélimar.
Only slight difference, as we kept focus on real user needs, we did not know exactly where this trip would make us arrive. I mean, sure we knew what user needs we had to respond to, but upon getting feedback from the plants, we could decide to add or remove features along the way.
“One vision”
The one trick was to always make sure everyone around the table shared the same vision. We kept refining our initial Product Vision and Story Mapping to keep them as clear as possible, and it quickly became the two indispensable items for the team, whether for user-testing, discussing technical strategy or business value.
Also, the vision being the vision, we kept routinely performing some tests or more simple observations in the field of the User Experience we delivered.
…and again
I already told about it, we were agile. This meant repeating this overall workflow all over again at different scales :
1. On a weekly basis, to evaluate again the Product Vision according to development contingencies and user feedback
2. Every 3 months, to prepare another full “release”, aka another batch of consistent features to respond to other user
Overall, this way of working was foremost based on two key tricks : mindset (the proper one) and communication.
After a few months into the project, things were clear that our initial “user-centric” approach was not just another “digital-transformation-washing” term to sell the stuff initially, but a real dedication to keep that “close-to-reality” mindset.
For sure we pulled out the big guns in terms of user research, and tried to refine and adapt our methodology all along the course of the project. But beyond the practice of user research, the whole team came to build this “let’s go to the field” reflex, which really made a difference.
Same for the vision and implementation, beyond the theoretical and methodical ways of working and formalisation we set up, having put in place all the proper communication channels and practices made the difference.
Despite the team being 2 and a half hours of flight apart (with good wind), we did spend a lot of time discussing tech, product design or business matter, with a clear product vision and story mapping at the centre of the table, allowing anyone to bring any insights in.
I’ll remember that very moment where we first deployed DWS in the pilot production unit, in Dacia Pitesti plant, Romania. The whole team was proudly standing near the production unit, as the first screens went live, to see Operators and production unit Managers make use of this brand new tool (they were basically switching from pen and paper to a way friendlier and more efficient digital tool).
Of course, Murphy’s law came in. Watching the first users interacting with the system, we could notice a bug.
The whole team quickly ended up on the field, amongst the users, analysing the issue.
I won’t lie, that wasn’t a great time (hopefully things were fixed fast). But it prove, as the team was only fully put up for only a few months, that this user-centric mindset and seamless communication would work.
Post scriptum
In 2017, after I spent 6 months at the heart of design, helping craft the onboard experience for future vehicles (now the Smart Touch and Edge which recently came out, for the connoisseurs), I pushed the doors of Groupe Renault Gradient aisle of the Technocentre (the gigantic place where everything starts, near Paris).
Behind this doors was the heart of the manufacturing department.
Yes I am going to sound lame and uninspired, but I did learn a lot professionally (and personally, but that is not the point here), practicing User research and Product Design in such a challenging context, dealing with experts in their field for which I had to push my boundaries and refine my ways of working.
Still uninspired, yet true, I did learn a lot alongside DWS team, on everything aside from Design, from project management to product development.
That was an awesome challenge.
Even though I speak about the project in the past, Digital Work Station is now live and daily used by over 2000 people across more than 10 Renault plants across the world. I just recently left the team after more than 2 years working partly on this project, to focus on other challenges, but the team keeps working with a very User-centric approach.
I want to make special thanks to all my teammates on Digital Work Station, with whom I learned a lot as a Product Designer, and who made this Digital Manufacturing journey really exciting.
