Designers continue to evolve.
In breadth, skyward and even sideways.
If earlier it was enough to be called a designer and learn to pronounce the word "Photoshop" without hesitation, now these skills are clearly not enough to find a decent job.
One of the types of designers in a fairly new direction is grocery. In the article, it is about him that I want to talk about.
I will hit the theory and practice.
In theory, I want to figure out who he is and what they want from him.
In practice - describe the process of work of this very designer on that very product.
Go!
Part one. Theoretical.
Who is, how much is it and what is expected
So, in the first lines of my letter, dear audience, I want to nevertheless explain what kind of animal such a “Product designer” is and what companies want from him, accepting their glorious ones.
First of all, I turned to courses that teach this very product design.
Here's what the courses say.
Netology promises a salary of 120 thousand. rubles
“UX / UI designer, product designer is one of the most demanded digital professions with ample opportunities for growth and high salaries.
It combines analytics and creativity, engineering approach and non-standard solutions. The competent work of the designer increases the client's profit and improves the user interaction with the product. "
Skillbox lures with a salary of 80 thousand.
“A product designer is responsible for creating and developing a product, from idea to market launch.
You will learn how to think through a business strategy, work with an IT team, conduct research and design design systems. "
Bangbangeducation is modestly silent about the monetary awards.
« , , , . . . , -. , . — .»
In general, everything in the descriptions is rather blurry.
Now let's take a look at hh.ru and see what employers really expect from a person called a product designer.
I acted clumsily and without any frills: I typed “Product Designer” into the search box and wrote down frequently encountered requirements.
Note to the hostess: in vacancies, the level of salaries is often not indicated, so the real picture is quite difficult to understand.
But I can grieve the promises and the expectation of salary from 100 thousand.
There is, there are companies that want a lot, but are not at all ready to pay much for it.
Well, they drove now according to general requirements :
- Experience in design and other software (Sketch, Zeplin, Figma, InVision, Adobe Photoshop, etc.);
- web, iOS Android ( , , );
- ;
- . , , , . , , , , ;
- . , , , , . , ;
- ux- — , , ;
- , ;
- . ;
- - , ;
- - ( : , , );
- , ux ;
- . , , ;
- frontend , . frontend , , , ; , - front ;
, . ;
And so, on the little things: the skills of presenting your work, the ability to reasonably argue with developers, self-organization, multitasking, etc.
In general, the requirements are quite extensive. Somewhere more, somewhere less.
Hopefully the main direction is clear.
A product designer should ideally combine a designer, an interface designer, a business analyst, a researcher, a speaker, a creative logician, and generally a wonderful person with a wide soul and powerful outlook.
In fact, everything is different for everyone.
But I know for sure that some part of the formidable requirements, without which, well, you can't pull the work in any way, in fact, turns out to be either unnecessary, or in a very small volume.
But this is my personal experience. Maybe someone is not at all like that.
The reason for this state of affairs is quite trivial: there is simply not enough time for all these lisu-pusu with research, testing and other crap. Because marriage is unbearable and the party said it was necessary, but we said yes.
And when you are a Swiss, a reaper, and a gambler in one person, then, of course, there is no strength to break from one big product designer into a bunch of small ux and ui -designer, ux-researcher, copyist, artist and analyst, there is simply no strength ... By the way, time too. But here everything, again, depends on time, complexity and other celestial bodies.
Honestly, I think that someday the man-orchestra will end and one product designer will fall apart into separate specialties. Because the load is quite high, and everyone has a different mindset.
It's like a story with layout designers.
Sounded good in theory. In practice, I have not seen a single layout designer who could make a high-quality design from scratch and vice versa. Perhaps I was looking badly or my vision is failing me.
But in the meantime, I sit, dangle my leg, complain about life and call myself a product designer, I want to share my experience of how I built the processes so that later it would not be excruciatingly painful ...
Because you still have to do it.
Well, how?
First, take the time and build the process of working on the product so that after the launch you do not fall into a nervous swoon from the realization that instead of the user's happy laugh, you hear his chosen mate. Well, developed, again, as it is not good squinting in your direction.
Part two. Practical.
Based on a true story.
I will not say that on all projects I managed to do as intended. But there were… there were bright spots in my biography when it worked out.
And my story will be about these bright spots.
Here it is worth paying special attention to the fact that for the last four years I have been developing projects from scratch. Therefore, the description of the process will concern them. But something tells me that the process can be applied to ready-made products.
And yes, in the article I will only touch on the process of developing and launching exactly new functionality. About generating hypotheses, collecting feedback and so on later, otherwise there will be a lot.
So…
Collecting requirements from the customer
Requirements can be collected from the Product Owner, customer, or other responsible person.
At this stage, it is important to understand how it works now and how it is seen by the person in charge. And not only here and now, but also with a gap for the future.
After all, when you see the whole picture, and not in pieces, it is always easier to lay the foundations for further scaling and refinement.
Requirements must be collected carefully, without leaving a single white spot.
The good news is that this should be done by a business analyst. I found out, wrote it down, brought it, made a "Smack" and waved my pen goodbye.
But with the bitter experience of a broken phone under my belt, I'm sure a product designer should do this. Well, or be present at the collection of requirements.
Because there are things that are not so important to the analyst, but when designing an interface, there is nothing without them. Therefore, he himself and only himself, well, or next to him, like a piano in the bushes with a notebook, a pen and a voice recorder.
By the way, I want to say about the dictaphone separately: if you don't use it in your work, start using it. The function is disgracefully useful. When you know that the entire conversation is being recorded, you can focus on it without losing your focus of attention along the way, being distracted by the recording, and so on.
Collecting requirements from the user
This is the other side of the coin.
Now you understand how it works at the top, and now you need to go and dig deeper. It is necessary to dig in the direction of those who know not only the tops, but also the roots.
Sit and see how he works with what he already has.
Ask what suits you and what doesn't. And as we would like. What is important when taking a certain action, making a decision, and so on.
Even if we do something that has not yet been done, they still somehow solve these problems.
Having poked with a stick in both directions, you already have a more or less intelligible picture with which you can work.
Another important thing: how it works and what is wrong, it is better to learn not from experts, but from end users. Because experts may only have theory or memories of days gone by, while end users have real practice, pain and tears.
Why am I paying attention to this? Because, again, bumps from practice. I collected the problems from the experts, graduated and went to see how happy the end users are for the happiness that has fallen on them in the form of solving their problems.
And suddenly, all of a sudden, it turned out that some of the problems were not valid, some did not arise here and not at this time, but some generally sounds strange and they are poor, what to do with it. In short, thanks, we decided, though they only made it worse.
User path diagram
This part can be called CJM, you can still somehow.
Its essence lies in the fact that after the received heap of knowledge, this heap needs to be transformed into some kind of fertilizer for further work, this time. Two - to decide whether everything is understood, taken into account and written down from the words of the victim correctly.
Let me remind you that I am now talking about the development of a new product. How I did it. Perhaps someone does it differently or does not do it at all.
And I took and laid out the entire user path of use with some function from point A to B, from B to C and so on.
Since I often had to do something that did not yet exist, I could not convey real problems, joy, and so on.
I figured, in theory, that there might be, at what moment they risk turning to the dark side of evil, going the wrong way, and so on.
Thinking over each step with possible options for problems, solutions, branches, etc., it is easy to see if you yourself understood what you were going to do (yes, even at this stage, after all the conversations, you can stumble upon an unknown piano in the bushes, then go and to clarify something else). What kind of weapons in the form of buttons, information, pictures and cats will you supply your future fighter?
When the whole path is clear, like a baby's tear, you can already start the prototype.
Prototype one: paper
I don’t know, maybe this step is not mandatory for someone, but I always do it. It helps you quickly skim and fix solutions without being distracted by the beauty of buttons and gradients.
Papers can be arranged in a row and evaluate the logic and clarity of the future product.
On pieces of paper, you can even write down some points that you need to think about or immediately write out emerging questions that need to be clarified with the development, for example.
Prototype two: dynamic
I do it in Axure.
Honestly, I tried it in other programs, but it's not convenient for me, especially when there will be a large enough number of screens.
A dynamic prototype is needed to show the higher powers that everything is going as it should and the user at the time of testing.
I will not say that I design it directly, but I do some important accents and colors.
Prototype testing
Running through a script with a prototype helps make sure you get where you want to go. Or maybe they got, but not there. Or maybe they didn't hit at all.
In any case, the prototype transfers all the edits easier than the product launched in production.
I test for passage according to certain scenarios, how much the user understands the meaning of the symbols, whether it is convenient for him to receive information, etc.
I will not say that everything is going smoothly and correctly.
There were also time limits when you just come and show the result of your work. Like, look: you asked, and this is what we did. Then you sit and listen to feedback.
The first time I thought that figs from this approach would turn out good, but no. Errors, incomprehensible and controversial moments were still found.
Therefore, I concluded that if it is impossible to allocate time "to talk", then you can limit yourself to the show, collecting feedback.
It's definitely better than nothing.
Show prototype development
In general, such a focus is not always obtained, but I think it is important to find time for both sides.
Often times, when time is limited, something can be simplified without losing quality.
You can also note the places that will require a more detailed description of the logic of work, so that the developers later live easier.
Tadam! The home stretch: design
There is nothing special to tell. You sit down, open the program and begin to draw, well or not, what you worked on in the previous series.
Time allows - you go to gain visual and other inspiration on the resources, the names of which cannot be pronounced, because lately they are often hated.
Transfer to development
Previously, I described scenarios in the user story format.
It sounded something like this:
I, like ..., I want ...
Further, the function itself, actions with it by the user, additional features, etc. were described.
It turned out that sometimes it turns out a lot and no one wants to read it, so I began to sculpt notes in the prototype itself and lay out in miro the way is with already designed screens.
It turned out that it is much more convenient for developers to work this way.
They see everything at once, they can ask questions or stick stickers so that they don't forget something.
Actually, this is almost all that I wanted to tell about how a product designer should work with a task.
Conclusion
I repeat that this is my vision and my experience.
Each of the steps is important to make it work well. And each step takes time.
This is probably why I don't really believe in the story that the position of a product designer will live for a long time. Well, either everyone will have a bag of time, or something will not be worked out so carefully.
I would very much like to know your opinion on the construction of work processes, responsibilities and capabilities of a product designer.
Will this profession be relevant in the future or will it eventually disintegrate into individual narrow specialists?