I am fairly new at design. After several years working in customer service and other various industries, I decided to pursue a new career. That began with an internship at House of van Schneider, much of which I documented here on the blog. And I haven’t stopped since.
The last week of my internship, I accepted a contracted position as a junior designer at a unique and forward-thinking design agency here in Austin. Now, six months later, I am officially an associate product designer. I have experienced a lot of firsts over the last year and working at a design agency was a big one. I haven’t stopped learning since my internship and I certainly don’t expect to. In that spirit, here are a few insights from my first six months into agency life.
Understanding lingo and asking questions
I have found that one of the more difficult aspects of starting a job in a new industry is getting accustomed to industry-specific lingo. There are many ways to say the same thing when it comes to product design. For example, some people might call the little window that pops up when you click a link a “modal” while others might call it a “pop-over” or a “pop-up.” Now let’s look at the software we use to create designs: What one software calls a symbol, another calls a component. An “artboard” in one software is called a “document,” “page,” or “frame” in other software. And we haven’t even gotten to the general industry terminology yet. Words such as “ship,” “backlog,” “kanban,” and “standup” are thrown around on a daily basis. For someone who doesn’t come from a design background, all of this can be very overwhelming.
I wish I was given a little handbook on my first day defining all the industry jargon, but of course nobody is. I was thrown into a sea of unfamiliar words and processes. In these situations, I believe in the importance of asking questions and that it is always better to be open, honest, curious, and communicative.
My first day at work, I asked my design director and the CEO what a “standup” was. It’s been six months since that first day and it sounds like such a silly question to me now, but I’m glad I got clarification on day one so I wasn’t left wondering and hoping the definition I had created from context clues was correct.
"I soon realized that formal presentations aren’t the only times I’m actually presenting my work."
Your design is only as good as your presentation
Tobias once told me that your presentation of a design is half the battle. When I first heard that, it was difficult for me to apply that to my work; I didn’t give many formal presentations during bootcamp or my internship. So I just kept that tip neatly stored away in the back of my mind. I soon realized that formal presentations aren’t the only times I’m actually presenting my work.
Often, I am presenting on a much more casual basis to my peers, my design lead, and to designers, engineers and project managers on the client’s side. Presentations aren’t limited to long slide decks; they include times when I’m sharing a small design update with my team during an internal 15-minute standup, or when I’m showing the work I did over the past week in response to a project manager’s request.
Any time I’m sharing my work with someone, I’m giving a presentation. At these times, it’s important to go into the meeting with intention. If I’m presenting work to a client with the intention of shipping my design, I need to be able to defend my design decisions no matter how big or small they are. Explaining why I made my decisions is crucial to building trust and a healthy relationship with the client. Although we work as a team with developers, project managers, etc. to create a product, they look to me as an expert in the field of design.
When presenting a design internally, I need to be clear on my position on the design and where I’m looking for feedback. This approach gives me practice presenting (in a casual, less-judgmental setting), helps me develop a rapport with my teammates and teaches me how to take constructive feedback.
"I’m never going to have everything laid out nicely and neatly for me exactly as I’d like."
Learning on the fly and adapting
The digital design industry, or more broadly the tech industry, is relatively new and is evolving rapidly. With all the new design software, news, trends, gossip, etc. that circulate the design community every day, it’s just impossible for anyone – no matter how experienced – to be on top of everything design. I worked very hard to change careers this past year and one attribute I can credit my relative “success” to is the ability and willingness to learn things on the fly.
When joining a new project, there will always be something new to learn and adjust to. Some of these variables may include how the design and development teams work together, what the client’s preferred method of communication is, internal and external management styles, and relationships working with different teammates. The list goes on, but the point is that I’m never going to have everything laid out nicely and neatly for me exactly as I’d like. Having the expectation that I need to “understand everything” before I start working can be seriously detrimental to the project health and my own growth as a designer.
Learning on the fly is a normal (and for me, very fun) part of the process! I’m of the mindset that the best way to grow is to dive straight into the work, make mistakes and learn. People I work with will respect me as long as they see the effort I put into my work, but if I let my fear dictate my approach to work, I rob myself of that opportunity.
Pushing back and problem-solving
I love being a designer, two reasons being that my job lends me more creative freedom than many others and, at its core, design is about problem-solving. At my previous non-design jobs, the work dynamic was as follows: boss or client tells me to do something and I do it. There usually wasn’t room for discussion, questioning or pushback. Luckily, I’ve found that this largely isn’t the case in design.
The majority of my tasks or requests come from a PM, and I have to remind myself that a PM is not a designer. People speak in ideas, so if a PM tells me I need to add some helper text on the screen, that might be his way of expressing that this design needs to be more clear or intuitive. As a designer, my job is to uncover the deeper problem underlying this ask. My job isn’t just to take the request as a prescriptive task, but rather to find the best solution to the problem behind the request.
By not assuming constraints and seeking to problem-solve, I am pushing the project design forward and advocating for the product and its users. I have learned that, in many cases, product “requirements” are in fact flexible and subject to change – as long as you make a good case for your design and know how to present it.
__
I hope some of these learnings can help some new designers out there, or even serve as a nice reminder for the seasoned designers reading this. I feel so lucky that I can share my experience here and am looking forward to what all I’ll learn over the next few months as an official associate product designer!
