Why don’t we treat our colleagues like we treat our users?
When I start a design project, my first goal is to really understand the the people that will use the tool we are building. I spend time doing interviews, collecting and organizing insights, and working hard to get into the mindset of the user.
If you are on a team that employs this UX practice, you’ve probably seen the benefits it provides to the product.
However, One thing I’ve observed, and I’ve been guilty of myself, is we rarely apply these same UX principles when interacting with our colleagues.
Why is that? Maybe it’s because we work with them everyday, so we think we know a lot about them. We are in meetings with them, so we believe we understand their role and responsibilities. We see the actual thing they produce, so we assume we know how they got there.
Whatever the reason, I want to challenge everyone to treat your colleagues with the same curiosity, respect, and interest as you treat your users.
So how can we do this? Here are 4 things to think about doing to begin to treat your colleagues like you treat your users:
First — Ask more questions.
Ask questions you think you already know the answer to - you might be surprised by their answer! Ask questions that help you learn things about their role and responsibilities, the challenges they face, and how you can better work together.
For example, you could ask:
- How do you define your role at this company?
- What are you accountable for in a project?
- What is the most challenging part of being a developer?
- As a project manager, what is the hardest part of a project to handle?
- How does this project compare to other things you are working on?
Second — Make less assumptions with your colleagues
When we are building software for users, it is unlikely we can talk to every user at a frequency that allows us to get answers for every single design decision. Therefore, we make assumptions in order to build something. Assumptions are a necessary part of design. However, with your colleagues, assumptions can be even riskier. You aren’t building a piece of software that can be changed with a new design and new code, you are building a relationship. And we all know that changing relationships and human behavior is far more difficult than updating software features. So assume less. Communicate more.
Third — Get some data
Use a google form or a Slack poll to ask a group of people some questions. Then, share your findings with the group and use it to start conversation. Here are some survey Ideas:
- What is the most effective way to communicate with you?
- What is the thing on this project that keeps you up at night?
- What makes you most excited to come to work?
- What is the part of your job that goes the most under appreciated?
- Is there anything that prevents you from doing your best work?
Or you can ask simple social questions like “What is your go to music genre?" Or "Would you rather drown or get hit by a bus?" Ok, maybe stay away from the morbid questions.
Fourth — Eat lunch
Simple, right. And I bet most of you do this everyday. But my actual suggestion is to ask someone out for a one-on-one lunch. Someone you don’t know that well. A new team member. Or someone that you don’t get time to talk with during the day. It can be awkward at first, but it will pay off in the long run.
Here’s the bottom line. Apply the UX best practices to your everyday life. Learn as much as you can about your colleagues through interviews (or seemingly casual conversation). Study them in the same way you study your users. Test out new approaches and see if it helps solve problems for your colleagues.
This will open up doors to allow you to apply UX practices to the product itself in an even more effective way, because you not only know the users of the tools you are creating, you understand those that you are collaborating with.