Think back to your first few months at your new role. What have you learned and where are you now? Have you had some discussions and experiences that didn’t go as well as you hoped? Perhaps you have used words to describe your process and ideas which didn’t land with your team? How did you adjust your commmunication?
When your team knows what you can do, they will ask you to do it! You want to be known for what you do and be able to expand this over time. (It’s called Growth!) Here’s some things I think about to communicate my expertise to help my team understand what I can do.
Don’t assume your team knows who you are and what you do. Also don’t assume that once you tell them they will remember. They are busy people, so remind them every once in a while.
You might get to do things you like that aren’t necessarily part of your job description but that are helpful to the team.
Avoid technical jargon
As designers we have a lot of industry terms that we know that are not common to others! Design Thinking, workshops, double diamond, etc. This jargon contains our shorthand but sometimes uses terms that are not immediately recognisable to others.
One is “Future Vision Design”. How far into the future does it go? What is it for? Is it a complete redesign or a reimagining of something and how long will it take? It literally means a design for the future and can help the team make decisions now in order to get where we want to go. “Future vision” as a term can be very scary because it’s so open-ended. How much budget will this dream design take? (Have empathy for your Product Manager and Product Owner).
Jargon tends to alienate you from your team (though I’m not sure why corporate jargon continues to grow and thrive?!) so instead of saying “high fidelity prototypes” say you want to show a “design” or a “prototype”. Use simple language like:
Hey, look at this design. Does it make sense for what we’re trying to accomplish?
When your team understands what you say right off the bat, they trust you more; you can expand on this trust and get a bit more innovative and creative. Jargon gets in the way of this so avoid it. If I hear “circle back” one more time. 🙂
Use pictures to communicate your ideas
The clearest way to show an idea is with pictures, diagrams, even a hand-drawn sketch. A picture illustrates a point beyond a shadow of a doubt and it can be discussed. If not, at the very worst they give us all something to push against and we can collaborate to get it right. If I try to explain it (using design jargon!) I lose my audience and have failed in my mission to communicate effectively.
A key part of this is don’t wait to be told what to do, but formulate your own ideas (visual examples) and then use those to generate discussion. Have a backlog of ideas ready when you need them. Then you can say:
Hey I was thinking about going in this direction based on previous discussions, does this sound reasonable?
Anytime I feel what I’ve said hasn’t been understood, the key issue is usually one of contextual understanding. My audience can only redirect me if they know what I’m driving at. They must understand the context.
Workshops and retrospectives
I love a good workshop, not going to lie. Design Thinking is my jam. Collaborative communication where everyone can participate pleases me to no end. Using a session to ask questions with a beginner’s mind helps your team open up to you. Can’t think of a better way to get great feedback than by asking:
Help me understand the struggles you deal with in your day to day work.
A UX Retrospective is also a great way to communicate and get feedback for what you have done. They are a clear and honest rewind presentation covering a project you undertook and the steps you took to make it work; also where it went wrong. Talk about your thinking process and techniques and also cover why you made certain decisions. What sources of information do you draw from? You might find your audience gets curious and wants to investigate those sources as well.
Solicit feedback from your team
One-to-ones are an especially great way to build trust and understanding in your expertise and your methods. Asking for feedback helps your audience feel involved in your process. This involvement is inclusion and inclusion breeds trust. Always be ready to solicit feedback by keeping your idea pipeline full. Miro and Figma are tools you can use to help you catalogue these ideas.
A great example of this is when you come up with a plan (I like to do this weekly to keep things moving; the last place I want to be is on the back foot!), verify it with your team.
Am I on the right track here?
As I’ve said before when talking to developers, when you ask for feedback it feels like you are in a vulnerable position. But it only is if you are making the feedback about you instead of letting your team help guide you in the right direction.
Document your process to improve it
Use tools like Miro and Confluence/Wiki to document your process. I’ve created wiki articles to document design decisions and have had a lot of success getting developers involved with this. Anytime a question comes up about a visual guideline or rule for a control, I document it; then we can refer to that rule later.
Of course it’s possible to over document so one rule I use is if I can find it on Google I probably shouldn’t put it in a wiki. Your internal documentation is particular to your team’s experience.
Start communicating your expertise to your team so you and your team can do great work.
