Features of approaches to design in the real manufacturing sector
When you design for digital products that will be used by people whose habits and usage patterns you can predict are not so difficult. You almost always know that the person on the other side will hold the smartphone like this, reach for the elements and controls with your thumb like this, and so forth, so on and so forth. For example, in B2C there is a certain set of tools that help the designer in research. There is a generally accepted set of rules according to which you collect feedback, grope for possible problems, put forward hypotheses and so on. For example, here is a fairly clear and convenient framework:
For people accustomed to the design of products used by millions of users around the world, this framework is familiar (in one form or another).
When products think that they know exactly what the user wants,
but all this undergoes rather non-weak changes when you start making design in the enterprise. Let's start with the fact that we have no customers as such - we have users. And the thing is that we are very close to the users. Not in the plan that there is an account, and we can view a detailed information about it, the usual orders and behavior model, no. We know that this particular user is Sanya, who climbed onto a 20-meter tower yesterday with you, in order to use your application to write data to the bypass log. And that Sasha’s daily tasks are quite complex and non-trivial.
My name is Lev, I am the leading designer of the Digital Technologies function in SIBUR, and I will tell you about how applications and interfaces designers work in conditions when a part of your users is a team of track workers at the production site in Tobolsk who use your application a little Not in the conditions in which you made this application.
Let's immediately determine that a designer is not a person who will draw you a couple of beautiful pictures or make a traveling menu on a mobile phone. The designer is responsible for a single work product as a whole, for how it is perceived by the user, what experience it brings and what real tasks it helps to solve.
The digital design division appeared in SIBUR not so long ago, but we have already found a lot of opportunities to simplify the life of an employee in an enterprise. For example, we recently wrote about mobile rounds . De facto, this is the third large iteration of the process. But between the classics of the genre of the form “write everything in a paper notebook” and our application was another stage.
When the drivers first came to the technicians with the request to come up with something more fun notebooks, their problem was solved approximately as it usually happens with SAP in companies. People were given essentially a good box solution, which they customized, set up and allowed to sail. But they didn’t really think about the process of using this solution. Yes, people have an electronic magazine of rounds. But his synchronization caused a number of questions - it was necessary to connect the crawler’s smartphone to the special computer twice a day (at the beginning and at the end of the shift) with a cord to transfer the information to the archive. The procedure took about 30 minutes. Obviously a little is not what you want, when the shift is over and you are ready to go to the family, and here this pribluda sends the data on the cord for half an hour. Where is the convenience for the user?
It ended in the end, all the same, they returned to paper notebooks. Why? Yes, because it is more convenient. People use what is more convenient. If you did something uncomfortable - they will not use it. Therefore, when our division took up the solution of the problem, we went primarily from the comfort of users and from their needs. This is logical and rightly so - they will use the fact that you will happily design. And in conditions that are significantly different from your openspace.
This was the first step. Now we are actively implementing our approach into the well-established SIBUR system, the designers are negotiating with representatives of various business lines so that everyone feels the importance and feasibility of this approach.
Here is another live example. We have a laboratory that constantly takes samples of finished products for quality. Still, the production of petrochemical, it is necessary for all to follow. And this laboratory interacts both with the production itself and with the state control bodies, carries out the calibration of the production itself. And laboratory staff should take samples regularly.
Tobolsk, -40, dark, visibility is not really, you go to take samples. You come to the guys from the digital division and happily report: "Everything, we have solved your problem with the pieces of paper, on you, man, smartphone." And you sit and think - well, go nuts now, climb 20 meters, and there’s still a smartphone to get and poke something.
In gloves with the parameters “Fine motor skills -50”.
And here for us as designers there are two quite important tasks.
Without the context of using dash with two, we would have made such a case. And in the case of the context, we bother very much.
Suppose you need to collect feedback from users of your product. Here is how it usually works (on the example of banks). There is a call center with many calls. There are social networks where customers often complain about any shoals from the bank in general or your application in particular. There is an opportunity to go to the office and talk with customers there, ask around what they have, everything suits you, what you would like to change in the application.
At the enterprise in general, everything is different in this regard. This sometimes causes a pattern to break with designers coming to us from other companies. There you sat and inserted buttons into the application that millions of users run every day. And our development team can create and improve a product that 10 people use de facto. But the economic effect that your application can bring in conjunction with these 10 users is much higher than from all these multi-million dollar audiences. Therefore, fixing their problematic is very important.
The advantage here is that we have direct access to users. If we need to collect and calculate the user satisfaction index, or something else, we can simply collect them personally and clarify everything.
And what's even cooler - you can take a hard hat, a special piece and just go to work with them in the usual conditions for them for a week, in order to assess in real conditions what you do with your design and whether it is convenient for people. We are much closer to the user of our product. The same applies to onboarding - no misunderstandings and discrepancies. We collect the guys, show them how they solved their problem, what and where has changed, how to use it all.
Let's compare this process in B2B or B2C again. You had a great idea, you want to check it out. You start a couple of landings, you look at the feedback. You hang it all up with various metrics, you look at the numbers, check it on large audiences.
The company is all in its own way. Metrics are thought out by designers together with products at the initial stage. To measure such a metric is simple - you can go and work on it yourself for 10 days. So much for your validation.
It is important to remember more about this. Digitalization just for the sake of digitalization is idiocy. With the help of such digitalization it is possible to spoil working conditions for people very easily. There is a bunch of simple things that do not need to be digitized at all, which do not require smartphones, charts of all sorts and other things.
Despite the proximity to the user and the ability to frequently interview employees, the real CJM of the user, his 100% painted day to SIBUR specialists is not visible. Therefore, it is very useful to take developers for interviews with users.
Usually how the team notifies about the problem. A product comes in, assembles a team, says: “Guys, there’s a problem here.” Everyone is starting to think that this is some kind of half-conceived problem of a spherical user in a vacuum.
And here we are gathering developers and users, so that users can directly say what exactly they do not need in the solution of developers. Or that does not work as intended. And already in this situation, developed penetrate communication with users - you understand that it is specifically this person with the normal performance of work tasks because of you, because you entered some feature into the application.
Everything sounds simple - he collected two sides and let them talk. In fact, at the enterprise, it is difficult to do this because of the difference in mentality. Workers, walkers, employees of the enterprise and workshops perceive people from digital departments not just as another employees of the company, but as a separate subculture. Like a bunch of punks who sit on the Internet, they design their own design, and they, normal people, then rake the consequences of all this.
And it is necessary to work, nobody canceled CJM, it is impossible without it. We have no project starts, if there is no exact understanding of how the user will follow the process. There is always some business process as is, everyone around will say that yes, everything is cool, everything works exactly as intended. And the people at work will tell you the truth - yes, it’s not working. And to study this process you need to spend time. Sometimes a lot of time, observing all the rules of the castdeva.
CJM is generally fashionable. Almost everyone who begins to broadcast that the company uses Agile, Scrum, and even a pair of markers bought for boards, one way or another they say about CJM. But in practice they give him less attention than he demands. With us now, CJM is the basis of the basics. We throw a peculiar map of actions on people just on the paper: a process - action - a problem - a solution. And without an understanding of this card, even starting to throw up your hypothesis does not make sense.
Because it turns out that you are doing something for the view, but there is no benefit from it. For example, employees appealed to you, they said that they have a problem with maintaining paper records and the like. And you went and bought them an interactive panel of 64 inches. Did you solve their problem? Yes, you just bought them a panel. Now they have a problem with reports and a hefty panel. You must clearly understand what the problem is. And people can express their opinions on how to solve it.
Plus it's important to work with expectations. People quite often can request the necessary features themselves, this cannot be ignored, because they are the end users of your product. Sometimes an employee of the digital division can think that he is more visible, and the people outside the perimeter are not in the subject even of their own members. Reality makes its own adjustments - we have very much pro-employee production workers.
Therefore, we create common chat rooms with them, in which they can directly send us their Wishlist to new features. Often, however, it turns out that the user describes a new and necessary tool, and you are responsible for him - a man, the same Realtime Board, just start using it to solve the described problem.
Products keep track of this and constantly collect feedback through available communication channels - it can be chat in telegrams, who has it, or chat in vibe, or the same Typeform.
In general, we get a slightly inverted classic framework, because we work from CJM, with an eye on users right away, this is the starting point of any task.
In one of the following posts I will try to tell you about the interfaces in a large enterprise. Here, too, things are not as simple as they seem. Starting from the fact that the interface buttons can be the size of your 13-inch MacBook (because it is necessary), and ending with the correct selection of font pairs. Because you can't just take and use standard visual presentations of reports and statistics when it comes to the 75-inch touch panel.
Moreover, even developing such buttons only on a poppy without being tied to the panel itself will fail.
By the way, now we have 2 open positions for smart digital product designers. Write to me at solomadinla@sibur.ru - I will definitely answer
- define the client's task;
- form your hypotheses;
- think over metrics;
- define context of use, CJM, other;
- consider the decision and its validation.
For people accustomed to the design of products used by millions of users around the world, this framework is familiar (in one form or another).
When products think that they know exactly what the user wants,
but all this undergoes rather non-weak changes when you start making design in the enterprise. Let's start with the fact that we have no customers as such - we have users. And the thing is that we are very close to the users. Not in the plan that there is an account, and we can view a detailed information about it, the usual orders and behavior model, no. We know that this particular user is Sanya, who climbed onto a 20-meter tower yesterday with you, in order to use your application to write data to the bypass log. And that Sasha’s daily tasks are quite complex and non-trivial.
My name is Lev, I am the leading designer of the Digital Technologies function in SIBUR, and I will tell you about how applications and interfaces designers work in conditions when a part of your users is a team of track workers at the production site in Tobolsk who use your application a little Not in the conditions in which you made this application.
Let's immediately determine that a designer is not a person who will draw you a couple of beautiful pictures or make a traveling menu on a mobile phone. The designer is responsible for a single work product as a whole, for how it is perceived by the user, what experience it brings and what real tasks it helps to solve.
The digital design division appeared in SIBUR not so long ago, but we have already found a lot of opportunities to simplify the life of an employee in an enterprise. For example, we recently wrote about mobile rounds . De facto, this is the third large iteration of the process. But between the classics of the genre of the form “write everything in a paper notebook” and our application was another stage.
Push off from users, not from business
When the drivers first came to the technicians with the request to come up with something more fun notebooks, their problem was solved approximately as it usually happens with SAP in companies. People were given essentially a good box solution, which they customized, set up and allowed to sail. But they didn’t really think about the process of using this solution. Yes, people have an electronic magazine of rounds. But his synchronization caused a number of questions - it was necessary to connect the crawler’s smartphone to the special computer twice a day (at the beginning and at the end of the shift) with a cord to transfer the information to the archive. The procedure took about 30 minutes. Obviously a little is not what you want, when the shift is over and you are ready to go to the family, and here this pribluda sends the data on the cord for half an hour. Where is the convenience for the user?
It ended in the end, all the same, they returned to paper notebooks. Why? Yes, because it is more convenient. People use what is more convenient. If you did something uncomfortable - they will not use it. Therefore, when our division took up the solution of the problem, we went primarily from the comfort of users and from their needs. This is logical and rightly so - they will use the fact that you will happily design. And in conditions that are significantly different from your openspace.
This was the first step. Now we are actively implementing our approach into the well-established SIBUR system, the designers are negotiating with representatives of various business lines so that everyone feels the importance and feasibility of this approach.
Here is another live example. We have a laboratory that constantly takes samples of finished products for quality. Still, the production of petrochemical, it is necessary for all to follow. And this laboratory interacts both with the production itself and with the state control bodies, carries out the calibration of the production itself. And laboratory staff should take samples regularly.
Tobolsk, -40, dark, visibility is not really, you go to take samples. You come to the guys from the digital division and happily report: "Everything, we have solved your problem with the pieces of paper, on you, man, smartphone." And you sit and think - well, go nuts now, climb 20 meters, and there’s still a smartphone to get and poke something.
In gloves with the parameters “Fine motor skills -50”.
And here for us as designers there are two quite important tasks.
- We use a digital input / output device. The crawler has a smartphone, they can track a number of parameters, something to help in the implementation of work duties.
- At the same time, it is necessary to try so that a person does not need to take out a smartphone from his pocket. Seriously. This is not at work for you at work every five minutes to get a cell phone out of your pocket and watch facebook. And there is a man -40 overboard. Gloves. Plus, the pipe height with a five-story building. Therefore, we program the physical buttons on android phones. So an employee may not even take a smartphone out of his pocket - he pressed a button in his inner pocket, launched a voice assistant (now we finish the same thing now), and fixed some kind of malfunction or divergence of standards.
Without the context of using dash with two, we would have made such a case. And in the case of the context, we bother very much.
Technique
Suppose you need to collect feedback from users of your product. Here is how it usually works (on the example of banks). There is a call center with many calls. There are social networks where customers often complain about any shoals from the bank in general or your application in particular. There is an opportunity to go to the office and talk with customers there, ask around what they have, everything suits you, what you would like to change in the application.
At the enterprise in general, everything is different in this regard. This sometimes causes a pattern to break with designers coming to us from other companies. There you sat and inserted buttons into the application that millions of users run every day. And our development team can create and improve a product that 10 people use de facto. But the economic effect that your application can bring in conjunction with these 10 users is much higher than from all these multi-million dollar audiences. Therefore, fixing their problematic is very important.
The advantage here is that we have direct access to users. If we need to collect and calculate the user satisfaction index, or something else, we can simply collect them personally and clarify everything.
And what's even cooler - you can take a hard hat, a special piece and just go to work with them in the usual conditions for them for a week, in order to assess in real conditions what you do with your design and whether it is convenient for people. We are much closer to the user of our product. The same applies to onboarding - no misunderstandings and discrepancies. We collect the guys, show them how they solved their problem, what and where has changed, how to use it all.
Validation of hypotheses and metrics
Let's compare this process in B2B or B2C again. You had a great idea, you want to check it out. You start a couple of landings, you look at the feedback. You hang it all up with various metrics, you look at the numbers, check it on large audiences.
The company is all in its own way. Metrics are thought out by designers together with products at the initial stage. To measure such a metric is simple - you can go and work on it yourself for 10 days. So much for your validation.
It is important to remember more about this. Digitalization just for the sake of digitalization is idiocy. With the help of such digitalization it is possible to spoil working conditions for people very easily. There is a bunch of simple things that do not need to be digitized at all, which do not require smartphones, charts of all sorts and other things.
And about the context
Despite the proximity to the user and the ability to frequently interview employees, the real CJM of the user, his 100% painted day to SIBUR specialists is not visible. Therefore, it is very useful to take developers for interviews with users.
Usually how the team notifies about the problem. A product comes in, assembles a team, says: “Guys, there’s a problem here.” Everyone is starting to think that this is some kind of half-conceived problem of a spherical user in a vacuum.
And here we are gathering developers and users, so that users can directly say what exactly they do not need in the solution of developers. Or that does not work as intended. And already in this situation, developed penetrate communication with users - you understand that it is specifically this person with the normal performance of work tasks because of you, because you entered some feature into the application.
Everything sounds simple - he collected two sides and let them talk. In fact, at the enterprise, it is difficult to do this because of the difference in mentality. Workers, walkers, employees of the enterprise and workshops perceive people from digital departments not just as another employees of the company, but as a separate subculture. Like a bunch of punks who sit on the Internet, they design their own design, and they, normal people, then rake the consequences of all this.
And it is necessary to work, nobody canceled CJM, it is impossible without it. We have no project starts, if there is no exact understanding of how the user will follow the process. There is always some business process as is, everyone around will say that yes, everything is cool, everything works exactly as intended. And the people at work will tell you the truth - yes, it’s not working. And to study this process you need to spend time. Sometimes a lot of time, observing all the rules of the castdeva.
CJM is generally fashionable. Almost everyone who begins to broadcast that the company uses Agile, Scrum, and even a pair of markers bought for boards, one way or another they say about CJM. But in practice they give him less attention than he demands. With us now, CJM is the basis of the basics. We throw a peculiar map of actions on people just on the paper: a process - action - a problem - a solution. And without an understanding of this card, even starting to throw up your hypothesis does not make sense.
Because it turns out that you are doing something for the view, but there is no benefit from it. For example, employees appealed to you, they said that they have a problem with maintaining paper records and the like. And you went and bought them an interactive panel of 64 inches. Did you solve their problem? Yes, you just bought them a panel. Now they have a problem with reports and a hefty panel. You must clearly understand what the problem is. And people can express their opinions on how to solve it.
Plus it's important to work with expectations. People quite often can request the necessary features themselves, this cannot be ignored, because they are the end users of your product. Sometimes an employee of the digital division can think that he is more visible, and the people outside the perimeter are not in the subject even of their own members. Reality makes its own adjustments - we have very much pro-employee production workers.
Therefore, we create common chat rooms with them, in which they can directly send us their Wishlist to new features. Often, however, it turns out that the user describes a new and necessary tool, and you are responsible for him - a man, the same Realtime Board, just start using it to solve the described problem.
Products keep track of this and constantly collect feedback through available communication channels - it can be chat in telegrams, who has it, or chat in vibe, or the same Typeform.
In general, we get a slightly inverted classic framework, because we work from CJM, with an eye on users right away, this is the starting point of any task.
In one of the following posts I will try to tell you about the interfaces in a large enterprise. Here, too, things are not as simple as they seem. Starting from the fact that the interface buttons can be the size of your 13-inch MacBook (because it is necessary), and ending with the correct selection of font pairs. Because you can't just take and use standard visual presentations of reports and statistics when it comes to the 75-inch touch panel.
Moreover, even developing such buttons only on a poppy without being tied to the panel itself will fail.
By the way, now we have 2 open positions for smart digital product designers. Write to me at solomadinla@sibur.ru - I will definitely answer