Think back to your first few months at your new role, and where you are now. Have you have some discussions 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?
When they know 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.
Avoid jargon
As designers we have a lot of jargon! 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? Is it a complete redesign or a reimagining of something and how long will it take? It literally means a design for the future – for what we are shooting for.
This 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 (though I’m not sure why corporate speak continues to grow and thrive?!) so instead of saying “high fidelity prototypes” say you want to show a “design”. Hey, look at this design. Does it make sense for what we’re trying to accomplish? Simple language.
When people understand what you say right off the bat, they start to trust you more quickly; you can expand on this trust and get a bit more innovative and creative. Jargon gets in the way of this so try to avoid it.
Use visual examples of your expertise
The clearest way to show an idea is with pictures, diagrams; even a sketch. Visual examples illustrate a point beyond a shadow of a doubt. 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 to cmmunicate 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. “Hey I was thinking about going in this direction based on previous discussions, does this sound reasonable?” The key to me is anytime I feel what I’ve said hasn’t been understood, the key issue is one of contextual understanding. My audience can redirect me if they know what I’m driving at.
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.”
Retrospectives are also a great way to communicate what you do. 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
Especially one-to-ones are a 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, asking for feedback feels like 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
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.
