What it’s like to be a part of your team remotely
Experience Design in the era of Covid-19
Looking back, it has been about a year since I started my journey as a UX Designer at Divar remotely. After completing the employee onboarding process, I participated in several meetings, including agile, product, one-on-one, and UX chapter, during the first month I joined Divar company. I’ve never expected to experience both excitement and stress at the same time. Fortunately, I could often hide these feelings while working remotely.
Divar is an established company with several cross-functional teams around significant sets of activities specialized in classified ads. Every team focuses on a different product vertical unique to them, and I was joined to the Automotive vertical by the UX manager’s decision as an Experience Designer. Azadeh tells more about Divar here:
Discovery: A lot of first-experiences
It was my first work experience that:
- I started remote working while living outside the HQ city
- I connected with new people through the only tools I had: Slack, Skype, etc.
- the design team had developed a design system (called Sonnat)
- UX Guild had more than 15 members (Designers, Researchers, Engineers, and Writer) (and today, we have 29 members!)
- documentation was part of the guild’s culture
- we had UX Engineers on our team
- the design team regularly evaluated the impact of its work on problem-solving
- the Product Manager I worked with was a UX Designer before his current role
- we had one dedicated UX Researcher for each team
Getting onboard and feeling part of a team comes with challenges when working remotely and when this whole Covid situation is happening. There’s a limit to getting to know the company’s culture, workflow, and product aspects when you’re never in the office or never see your colleagues.
After the first few days, I gradually joined the team and tried to get to know the people and their roles, but it wasn’t easy because the only guide for me was the Slack profile of the team members and the daily meetings.
To better understand the atmosphere and the company’s work culture, I spent a lot of time talking to my manager one-on-one and discussing these issues. She helped me a lot to gain a better understanding of the situation. I can say that UX Guild’s proper documentation was a beneficial mentor and reference for answering my questions. It also gave me a magnificent view of my interactions with different roles. It taught me how to proceed with a problem and how to utilize various tools.
To learn more about the product, I first talked to the product manager, who explained the history of the products, businesses, and competitors. I had some meetings with the former UX Designer of the team on how different product streams fit into designs, talking about who our users are and which touchpoints we could impact on.
Define: Challenges and problems
After I got the first and second stories and I began to work, we got a little closer to the OKR meetings, and well, because I still did not have a good knowledge of work procedure. I found out, unlike what I expected, I needed to make more effort. The first session was the OKR review and retrospective. After reviewing the previous OKR metrics, the technical team leader started the retrospective with the question of what bottlenecks we had in the work process in the last three months and what we want to be resolved in the upcoming OKR.
But their answers had more or less one general keyword:
- Engineer 1: “I think the design did not reach us in time, and this created problems that caused us to be workless for two days and have two days of hard work to meet the deadline.”
- Engineer 2: “In my opinion, our changes in designs and the back and forth between the design team and technical team and delivery time were our main problems in these three months.”
- Engineer 3: “I believe that design impacts our process which ….”
- Engineer 4: “to add a comment, the design was like ….”
- …….
It was the moment that I became worried, and I just found out what the team’s point of view was about design during this period and how this could be my main objective for a while. Although, after asking my colleagues, I realized that they meant the time before I arrived, and basically, no one could judge me because we had not officially done anything together. I tried to focus on understanding other problems regarding the design or the process we went through and have more interactions with my colleagues. If I want to point out the basic as well as more advanced problems and the concerns I encountered, at the beginning of this journey, they will be as follows:
- Disorganization, in a few cases, in design and the team
- Different Workflows among previous companies (implementation constraints impact the feasibility of the design; also, my design had to be based on the design system, and along with managing my time to write a document that was not part of my habit, I was always interested in.)
- Commenting and being involved in existing problems or for which no solution was provided, or the offered solution was not feasible for the technical team.
At the beginning of summer’s OKR, a new technical team leader was added to our team, so I had to reorganize an important role in my interactions and start building a new relationship, but other things were happening to me along the way.
- non-observance of boundaries by some colleagues
- the difficulty of judging people I did not know based on the things they had written
- giving feedback to people I could not judge fairly while I did not know them
- having too many context switches due to the presence of many product touchpoints and talking about a variety of different features on different platforms in different brands
- changing of designers on and on and the challenges brought us
- we had a competent technical team who were extremely fast through the development and implementation of the solutions, and the features should have been planned, so it was the moment that I felt excited about it, and it gave me a sense of competition though I was stressed to not coming up together
Develop: Ideation and test
But not all of these problems happened all at once, and it was possible to think of a solution for each of them.
For the problems we faced above, we came up with a series of solutions, in the team and even with the help of other technical mates outside the team, and tested them together, which sometimes resulted in our success and sometimes in our failure.
Disorganization in some cases in design and the team
My priority was to communicate frequently with the colleagues to understand their problems accurately and then speed up, which should have probably been much faster than usual. To solve this problem, I noticed a few points in the conversations:
For example, unlike other teams, because we had more web-client problems in the iterations, even more than mobile-client problems, the technical team needed to look at the flow of different products on the web. So I decided to start handing off web-client designs on Overflow like mobile side to understand developers better. Before that, we used to present only mobile application designs on Overflow for Divar.
Another problem we had was the lack of sessions to review the designs, which, at the suggestion of the technical team leader, we started with an interval of once a week. Then with the new experiences we gained, we decided to increase the repetition of these sessions to each iteration of 3 sessions. Therefore, we were able to transfer design decisions to the technical team leader in more detail and have more coordination; this decision helped us be on the same page with common opinions with the technical team much more than before.
Different workflows in previous companies
This is a problematic (obstacle) for anyone who wants to change their job platform, especially if it is a transition from a start-up company to an established company. Eventually, I was able to adapt to this issue.
Commenting and putting in context the problems that already existed
In the first three weeks, I joined the team, I had to make design decisions based on the process I was not involved in, and the other problem that made it worse for me was the kind of communication that the colleagues had with me. It means that instead of being in a group where I can get help from someone if I am not familiar with the context, a personal call was made, such as Skype, where I was usually needed to offer the colleagues a new solution. Even if I understood the problem, I would have liked to be more familiar with the context, and usually, my answer to people was that “it is all ok and we will get to the solution, but let me think more, and then we discuss it again.”
After a while, with the suggestion of the technical team leader to solve the problems as a team in Slack, many of these issues were resolved, and I also felt more part of the team, and things became more manageable for me. The technical team leader suggested that we create a channel in Slack for each story and prevent personal conversations about the problems so that all the members. They need to decide about a case that arises and make all the decisions in one place. Also, we could have an archive to make it easier for us to review them and understand the reasons.
After a while, this solution created another problem: the increase in the number of different channels, which I will mention the Switch in the context section.
Non-observance of boundaries by the colleagues
I can talk a lot about this, but to summarize, my experience of interacting with my colleagues in the early days and even in the first few months gave me the feeling that some team members did not consider the boundaries associated with others.
Disregarding boundaries included some behaviors or feedback. In the case of feedback, for example, when I did receive feedback that was not related to my role and position, I would try to emphasize that while I was paying attention to the other person and having inputs, I had the option of not taking the feedback into action. Or sometimes, it happened that I did not recognize the other party’s words as feedback, and I would notify him about this.
“Rejecting feedback can be as easy as saying no thanks or walking away or simply saying nothing. They offer, you decline, and it’s over. But sometimes, it’s more complicated than that. You say no, but the unwanted feedback keeps coming. It’s not just bothersome but destructive. This is when it helps to be explicit about boundaries.” Douglas Stone, in his book ‘Thanks for the Feedback.’
Through time, it became more evident. I went through several approaches and different ways, and finally, I saw the most straightforward route was to give direct feedback to the person. As for the other ways, I would like to summarize what I have learned. I can say that I should never depend on anyone but myself, and if I feel there is a problem somewhere, I should try to solve it myself.
It’s unclear what’s happening
Judging people is a subconscious thing that is more in conflict with “ethics,” but in the workplace, and given the organizational culture in which we work, sometimes it is inevitable. For me, judging in the workplace allows me to identify people earlier than usual. I can assume that I know them, which helps me communicate better with them. But with working remotely, I was handcuffed there. I could not get to know anyone quickly, and I did not have the proper tools and context to get to know people. It was not easy to distinguish a person’s intentions through the text, and also, voice call would not give us a 100% correct assumption of what a person means. For example, regarding a problem, there was a difficulty for the developer. After seeing the developer’s message, I realized that the problem bothered him or needed to fix it immediately. It created a bottleneck at that moment; it meant thinking about solving the problem from then on. The solution I found for this problem was to suggest video call sessions to precisely understand the problem and to what extent it arose, and when it had to be solved.
Taking the fear out of feedback
On the other hand, I struggled with giving feedback to people that sometimes I did not even know. It had the same difficulty of judging people even more.
Giving feedback to people we do not know or are not familiar with is sometimes a complex process, and sometimes this direct feedback can create new problems. A simple example is the tone and words you choose to go beyond the feedback boundaries, and if the person does not have a good understanding of what you are saying, it will cause problems. I tried my best not to give feedback beyond this framework even if I did not feel good about that person’s behavior, and I think I did it very well in some cases that I encountered.
Having too many context switches
Due to the nature of the team and the products we had, we could feel from the beginning what problems we were going to face. For example, I talked about the solution of creating a Slack channel for each story above. The problem we already had was that the number of slack channels was already high, and many channels would be added. I do not mean 10, not even 20 or 30; on average; we had between 35 and 40 problem stories in each iteration, which was expected considering the number of (technical) teammates. Managing and consolidating this issue was hard, but what did we do to make it a little bit easier for us?
I made a few suggestions that we acted on, and as a result, the situation got better for us:
- We suggested everyone use the feature of adding Slack sections and grouping chats. Also, we considered a Slack section for stories and some naming conventions to indicate story channels.
- Inside each story’s Slack channel, we had two pinned messages:
1. The description of the user stories was available for engineers (usually written by the Product Manager).
2. Links related to the design of that story included Zeplin and Overflow project links and the design doc link related to the story written in Slite. In that way, anyone who was new to the story could be fully aware of the context of the problem and have easy access to the design links and assets.
Evaluation
Since my first days at Divar, I have been less involved with “changes” in team issues. But in the last days of being with the team, I can say that due to the many actions and not being afraid of new experiences, and using the ideas of all the colleagues in all the roles in the team, we have reached a good place. Our team has good dynamics, and the design project, plus the implementation process, no longer raises concerns about speed. It is difficult to say that I did well in all areas, but I have learned to ask more, hear more, experiment more, and listen to different ideas more from others. So, as I help my teammates, I feel more being part of the team.
To summarize, all the thoughts in a team have been very effective in the development of the company. I wrote this text about the problems I was most involved in doing through the Covid situation. Still, indeed, the decisions and valuable work of other teammates, if not more effective, would not be less effective than my efforts to improve our team processes, and I hope it continues like this as well.
