A usability specialist is needed by everyone: big IT companies and small startups. About how the process of the work of usability in large companies is usually built on the site has been written more than once. And for some reason, the topic “how to take and organize the work within your team right now” (albeit small) has always been avoided.
We decided to fill this gap. Despite the fact that
Accounting. Contour (formerly Elba) is a project of a large company, we have always tried to recreate the atmosphere of a startup within a team. Therefore, the problems and nuances of working in a small team are well understood.
Place of usability specialist in the team
When our project was just beginning its existence (almost 5 years ago), the usability specialist was a visiting person. Today, in many companies, everything still works. But we quickly became convinced that the usability specialist is like a father: even if he tries very hard and is a wonderful person in general, he is still not part of the process.
For example, a usability task was posed to test a prototype with the user. He diligently executed it, prepared a report with recommendations and comments, sent it out and waited for the next prototype to be checked, often without waiting for feedback on his work. Comments, in turn, were not always taken into account. First, they were always in the wrong place at the wrong time. And secondly, you see, it is not always easy to take on faith the words of a person who comes to the team once a week and constantly tells you that you are doing wrong.
')
Then the understanding came that the place of usability specialist is in the team. True, where this place is, we also did not understand right away. It was not easy to enter a new link in years of well-established development processes.
So, by trial and error, we chose Kanban. This agile method made it possible to ensure that not a single task went into development until it was tested on users.

Frankly, not immediately the whole team understood the importance of these changes. Awareness came when designers and developers took part in testing for the first time and saw that the user is experiencing difficulties in working with the service: he doesn’t immediately find the right tab, does not understand where to click to send a report or switch to another document.
But not only participation in testing helps the team understand the user. The usability's task is to initiate various internal events: co-creating user personalities and scenarios of their work, drawing up a customer journey map, etc. This allows the team to better understand who they are making their product for and what “hurts” the users.
At the moment, to test a single prototype, we hold 5 meetings, and in the process of developing serious functionality - about 20 different meetings with users: this is complete usability testing and informal communication (there were cases when our usability specialist interviewed a person in a tram, hearing him talking on the phone about accounting).
Paper method
Previously, the development of a clickable prototype took up to a week, then it was tested on users, after that, as a rule, it was sent for revision (up to a week) and tested again, so that, only after all this, it was sent to development. Thus, it took a whole month to work out one new functionality. Therefore, we decided to simplify the process and test ideas faster. So, we gave the user a pencil and paper.
This made it possible to move away from simple testing of our ideas to jointly creating a product: now for an interview, the user himself or with our help sketches his usual work scenario. And then the present interfaceologists “animate” the drawing with stickers and you can immediately show it to other users and check the intended functionality.

It is convenient to shift sheets of paper, change places, glue stickers on them and move them, make notes and fix interesting ideas. Of course, the prototype on paper is an interface that has not yet been developed, but it is an algorithm that will show which way to go. And we spend no more than 20 minutes on this.
Of course, this does not mean that we completely abandoned usability laboratories with webcams and mirrored glass - they are needed for other purposes: a clickable prototype, a live system or communication with a focus group.
And when there is only an idea, a sheet of paper, a package of stickers and a pencil are enough.
What can be done right now
Small companies often have doubts: do they need a usability specialist? Can he afford them? Do they have enough knowledge to fulfill this role on their own?
Well, we hope that in the first part we managed to explain why a usability must necessarily be part of the team, and secondly, that usability testing is not a costly process. Now let's focus on how you can implement all this in your team.
The role of a usability specialist in your team, in fact, can be taken by anyone. The most important thing is to communicate with users. It is usually free. Moreover, users themselves are often willing to share their thoughts about your project, because they want a service that really suits them. Our first respondents were just such people, and as a thank you for participating in testing, we gave them our service. Now, we are trying to invite all kinds of people: from different fields, with different levels of training, and sometimes to those who have never used us before - they can be thanked for one of the largest networks (perfumery, equipment, etc.). ).
At the very beginning, you need to find out how users conduct their work, how their working day goes, with whom they interact, what they use. Pay attention to how the user performs various actions, what he says in the first place. By the way, if meetings are recorded on video (just make sure the respondent agrees to video filming in advance), then when re-viewing it is easy to notice the user's reaction. Emotions are not always easy to see while being tested, but they also play an important role.
But the most important thing: you should listen carefully to the client, understand and accept his comments, even if they are not always doable. The user, and you yourself, should understand that his words can neither be “right” nor “wrong”, they are just important for the development of the service.