I started my UX journey as a solo designer, and I found the dynamic of being on a team is totally different than being solo. When you’re solo, you don’t have to worry about collaboration or going to a ton of team meetings. You have enough other things to worry about on your own, though.
Having recently worked on an enterprise software team with Development, QA, and Product team members, I learned a lot about working together, design advocacy, and compromise.
I wanted to share some of the things that I’ve found to be important when working as a UX Designer in general, especially as the only one on a team.
Communication
I’m sure I don’t have to tell any of you that communication is one of the most important factors when it comes to working on a team. Regardless of position in your organization, everyone needs to be a good communicator.
*Being on the same page as your team is possible simply by attending stand-ups and staying active on team chats or emails.*Stay updated on what the team is saying and working on even if you’re not meeting that day.
Be clear about the goals and responsibilities of the team. Everyone should know what everyone else needs to do so if anything comes up, they know who to go to for questions or clarification.
I also learned to voice my opinions and concerns when they arose because it’s always better to talk about things too early rather than too late.
Collaboration
UX design is never done in a vacuum, so working with others is integral to the success of design, even if you’re the only designer on your team.
Personally, I worked very closely with my product manager, because he had much more domain knowledge than me and could help educate me on the more complex parts of our product.
When I had a question on technical capabilities, I would go to one of the developers. Luckily for me, they were always ready to explain something to me or go over an idea and the technical feasibility of that idea.
Although I was the only one doing the design work, I would frequently check in with my team to make sure I was on the right path.
Advocacy
As UX designers, we can hope that our teammates all understand what UX is and what our contribution to the product should be. Not everyone is lucky in this regard, so as designers we have to do our best to advocate for ourselves and our value.
*If the team is talking about a new feature or changing an existing one simply by suggesting solutions, part of our job is to redirect attention to the users, the research, and the business goals.*
By aligning these things in our thought process, we can make better decisions from the get-go instead of backtracking later.
The team dynamic will reflect how they approach problems and view the UX process. Some teams will see the value in things like research and user testing, others will see it as a waste of time. We have to adapt to our own environments and try to get on the same page as our team as best as we can.
Active Listening
Along with the other items on this list, this one is like a superpower if used correctly.
When you’re actively listening, you are fully concentrating on what is being said rather than just passively ‘hearing’ the message of the speaker. This comes in handy when your team is discussing things like the product roadmap, sprint goals, or when a team member is bringing an idea of their own to the table.
If you’ve concentrated on their ideas fully, you can give better feedback and additionally, get more out of constructive criticism that is bound to arise.
When you’re picking up on things like the speaker’s behavior, tone of voice, and reasoning for their statement, you’re already ahead of the game when it comes to listening comprehension.
Wrapping Up
Obviously I’ll never be done learning, nor do I want to be, but these are just a few of the main things I’ve taken away from my time working on a team building software.
- Communication
- Collaboration
- Advocacy
- Active Listening
Something to think about: As the only designer on a team, what kinds of things have you learned so far on top of these topics?
This was originally published on Prototyper.